From AI Pilots to an AI Platform: An Enterprise Agentic AI Architecture for Secure, Isolated Networks

Most large organizations no longer have an AI problem. They have an AI sprawl problem: dozens of promising pilots, each wired to its own data, tools, and security rules. As AI moves from answering questions to taking action, that sprawl becomes a cost problem, a speed problem, and a security problem all at once.

This white paper lays out a reference architecture for fixing that in the hardest environment we can think of: a large intelligence or national security organization running on an isolated, classified network with multiple internal security domains. The same ideas apply to any regulated enterprise, such as a bank, a hospital system, or a utility, that wants AI agents working across the business without giving up control.

Executive summary

The organization we describe already has most of what it needs: internally hosted AI models, enterprise APIs, identity management, knowledge repositories, mission applications, and data platforms. What it lacks is a common way for AI agents to find and use those capabilities safely.

We propose an Enterprise Agentic AI Platform built on three ideas:

1. Govern centrally. One shared control plane decides which agents, models, and tools are approved, who may use them, and under what rules.
2. Execute locally. Agents run inside each security domain, under that domain’s control, with no hidden paths between domains.
3. Reuse, don’t rebuild. Existing systems are exposed to AI through a standard interface, the Model Context Protocol (MCP), so every integration is built once and reused by every approved agent.

The result is faster delivery of AI capabilities, less duplicated spending, and a security posture that is stronger than today’s, because every agent action is identified, authorized, and recorded.

The problem: AI is growing up in silos

In most large enterprises, AI adoption has followed the org chart. Each mission area or department stands up its own assistant, writes its own connectors to the systems it needs, and works out its own security approach. Each effort makes sense on its own. Together, they create real problems:

• Duplicated work. Five teams build five different connectors to the same HR system, the same document library, or the same analytics platform, and all five must be maintained.
• Inconsistent security. Each project interprets access rules, classification handling, and logging a little differently. The weakest one sets the real security level.
• No enterprise view. Leadership can’t easily answer simple questions: How many AI agents do we have? What can they touch? Who approved them?
• Slow approvals. Without shared, pre-approved building blocks, every new AI use case goes through security review from scratch.
• Limited reuse. A great capability built for one mission can’t easily be offered to another, so good ideas stay local.

Why now: agents act, not just answer

Early AI tools were chat assistants: you asked a question and got an answer. Agentic AI is different. An agent is given a goal, plans the steps, and uses tools to get it done, such as searching a repository, opening a ticket, querying a database, or drafting a report from several sources.

That is a big step up in value, and in risk. A chatbot that gets something wrong produces a bad paragraph. An agent with access to real systems can take a wrong action. Once agents can act, questions about identity, permission, and accountability stop being paperwork and become the core of the design.

At the same time, the industry has converged on a standard way for agents to connect to tools: the Model Context Protocol (MCP). Think of MCP as a universal adapter. A system is wrapped once in an “MCP server” that describes what it can do and how to call it. After that, any approved agent can discover and use it in a consistent, controllable way. This standard is what makes an enterprise-wide approach practical today.

The guiding principle: build on what already exists

This proposal does not replace anything. The organization’s AI models, search and knowledge systems, identity services, and mission applications stay where they are, owned by the teams that run them today. The platform adds a thin, shared layer that connects them, governs them, and makes them safely available to AI agents. That keeps cost and disruption low and respects the authority of each mission owner over their own systems and data.

The architecture, layer by layer

The diagram above shows the full design. Reading from top to bottom:

1. Mission users and applications (the consumers)

These are the people and systems the platform serves: analysts, mission teams, mission applications with built-in agents, the general workforce, IT and cyber operations, decision makers, and developers building new agents. They sign in with the identity and smart card credentials they already use, and their role and security domain travel with every request.

2. Enterprise AI Control Plane (Tier 1: shared services)

This is the “air traffic control” of the platform. It does not run the agents. It decides what is allowed and keeps track of everything. Its main parts are:

• Agent Registry: a catalog of every approved agent, with its owner, version, purpose, and status.
• Model Catalog and Routing: the list of approved AI models, what each is approved for, and usage limits, so requests go to the right model for the job.
• MCP Capability Registry: the catalog of tools available to agents, with descriptions, owners, and certification status.
• Identity and Delegation: identities for users, agents, and services, plus short-lived, narrowly scoped credentials that let an agent act on a person’s behalf and no further.
• Policy Administration: one place to define access rules, classification rules, and guardrails.
• Evaluation and Certification: testing and approval of models, agents, and tools by risk level before they go live, and again when they change.
• Developer Portal and Orchestration Templates: software kits, documentation, and reusable workflows (including human approval steps) so teams build the right way by default.
• Enterprise Knowledge Services: shared search, retrieval, and organizational vocabularies, so agents ground their answers in the organization’s own authoritative information.
• Telemetry, Audit, and Governance Operations: enterprise-wide visibility, compliance reporting, and oversight of model safety and risk.

3. Domain execution environments (Tier 2: isolated by security domain)

Agents actually run here, inside each security domain, such as an agency-wide general domain and separate mission domains with stricter access. Each domain gets the same standard kit:

• A domain agent runtime where agents do their work
• A domain MCP gateway that every tool call must pass through
• Local policy enforcement using cached policies that fail closed: if the domain loses contact with the control plane, agents are denied rather than allowed by default
• Domain telemetry and logs that feed the enterprise audit picture

Crucially, there is no direct cross-domain access. An agent in one mission domain cannot reach into another. Anything that must cross a boundary goes through the organization’s existing, approved cross-domain processes, not through a shortcut the AI platform creates.

4. Federated MCP Capability Fabric

This is the connective tissue. “Federated” means each team that owns a system also owns its MCP server: they decide what the AI can do with their system, and they stay accountable for it. The fabric provides the common pieces around those servers:

• Capability discovery: agents can find the tools they are authorized to use by describing what they need
• Gateways per domain: authentication, routing, policy checks, and rate limiting on every call
• Standard tool contracts: consistent descriptions of inputs and outputs, so tools behave predictably
• End-to-end tracing: every tool call is tied back to the agent, the user, and the original request

5. Existing enterprise services and data (Tier 3: capability providers)

These are the authoritative systems the organization already runs: business systems (IT service management, HR, finance, acquisition), mission applications, data platforms, knowledge systems, and infrastructure services. They are reached through their existing APIs. Nothing is copied and nothing is duplicated, so the system of record stays the system of record.

6. Infrastructure and operations

Underneath it all is the infrastructure already in place: compute, container platforms for isolating workloads, network zoning and firewalls, encrypted and labeled storage, monitoring, and backup and disaster recovery. The platform runs on it rather than beside it.

7. Cross-cutting security and governance

Running down the side of the diagram are the controls that apply everywhere: identity and access management, attribute-based access control, classification marking, security monitoring, audit, model and tool governance, software supply chain security, and the organization’s authority-to-operate and compliance processes. And the whole environment has no public internet access: every model, data source, and service is hosted inside the classified network.

Following one request through the system

Here is what happens when an analyst asks an approved research agent to “summarize everything we know about topic X from the last 30 days and open a tasking request for follow-up”:

1. The analyst signs in as usual. Their identity, role, clearance attributes, and current domain are attached to the request.
2. The agent, running in the analyst’s domain, receives a short-lived credential that lets it act on the analyst’s behalf for this task only.
3. The agent asks the capability fabric which tools it can use. It sees only the tools allowed for this user, this agent, this domain, and this purpose.
4. Each tool call (search the knowledge repository, query the reporting database, create the tasking request) passes through the domain gateway, which checks policy before the call goes through.
5. Results come back with their classification markings intact, and the agent’s summary carries the correct marking.
6. Because opening a tasking request is an action, not just a lookup, the workflow pauses for the analyst to approve it.
7. Every step is logged and linked into one traceable record of who asked, which agent acted, what it touched, and what it produced.

Security and governance by design

For an organization like this, security can’t be added at the end. The architecture builds in the following from day one:

• Least privilege, five ways. An agent may do something only if the user, the agent, the tool, the domain, and the purpose all allow it. Any one “no” blocks the action.
• Agents never exceed their user. Delegated credentials mean an agent can never do more than the person it is working for, and usually less.
• Zero Trust. No request is trusted because of where it comes from. Every call is authenticated and authorized every time.
• Classification enforced end to end. Markings travel with data into and out of agents, and policy prevents information from flowing where it shouldn’t.
• Fail closed. When something is uncertain or unreachable, the answer is “no.”
• Risk-based certification. A read-only search agent gets a lighter review than an agent that can change records or trigger operations. Higher-risk agents require human approval steps and more frequent re-review.
• Complete, tamper-resistant audit. Every agent action can be traced and reviewed, which supports oversight, investigations, and compliance.
• Trusted software only. Models, agents, and MCP servers are signed, scanned, and tracked with a software bill of materials before they are deployed.

The key insight is that a shared platform makes security easier, not harder. Today, each AI project has to get all of this right on its own. With a platform, it is built and approved once, and every project inherits it.

The business case

Stop paying for the same integration over and over

Without a standard, every AI tool that needs every system requires its own custom connection. Ten agent teams that each need twenty systems can mean up to two hundred separate integrations to build, secure, and maintain. With a shared capability fabric, each system is connected once and each agent connects once: thirty connections instead of two hundred. That difference grows as AI adoption grows.

Faster time to mission impact

With approved models, certified tools, templates, and a pre-approved security pattern already in place, a new agent becomes an assembly job rather than a construction project. Teams can move from idea to approved, working capability in weeks instead of months.

Better return on existing investments

The organization has already paid for its AI models, knowledge platforms, and mission systems. The platform puts them to work for more users and more missions, instead of leaving each one useful to a single program.

Lower risk

Uncoordinated AI projects are where unmanaged risk accumulates: agents nobody is tracking, permissions nobody has reviewed, and logs nobody can join together. Central governance with consistent enforcement replaces that with a known, auditable inventory.

Mission autonomy preserved

Because execution and tool ownership stay with each domain, mission owners keep control of their systems and data. They gain enterprise services without giving up authority, which is often what makes or breaks adoption in a large organization.

A phased path to get there

This is not a single big launch. We recommend four phases, each delivering value on its own:

1. Foundation (about 3 to 6 months). Stand up the core control plane (agent and capability registries, identity and delegation, policy, audit) in one domain. Wrap three to five high-value existing systems as MCP servers. Agree on the certification process with security and compliance stakeholders early.
2. Pilot (about 6 to 9 months). Deliver two or three real mission use cases on the platform, starting with lower-risk, read-heavy work such as research and summarization. Measure results against the old way of doing things.
3. Expand (about 9 to 18 months). Extend execution environments to additional security domains. Open the developer portal and templates to more teams. Introduce higher-risk agents that take actions, with human approval steps.
4. Scale and sustain (18 months and beyond). Make the platform the standard path for AI agents across the enterprise, with ongoing evaluation, recertification, and a growing catalog of reusable capabilities.

Risks and how we address them

• “A central platform will slow us down.” Central governance, local execution: teams build and run their own agents. The platform gives them approved building blocks that make them faster, not a queue to wait in.
• Agents taking unintended actions. Least-privilege access, delegated credentials, risk tiers, human approval for consequential actions, and full audit trails.
• Cross-domain leakage. Separate execution environments per domain, no direct cross-domain paths, classification enforcement, and fail-closed policy.
• Locking in to one vendor or model. MCP is an open standard, and model routing allows models to be added or swapped without rebuilding agents.
• Adoption. Start with use cases that mission users are asking for, make the approved path the easiest path, and publish early results.
• Approval timelines. Bring security and compliance teams in at the beginning, and certify the shared platform once so individual agents inherit its controls.

How to measure success

• Number of reusable capabilities in the catalog, and how many agents use each one
• Time from new AI idea to approved, working agent
• Integrations avoided compared to building connectors project by project
• Share of AI agents in the enterprise that are registered, certified, and monitored
• Policy violations blocked, and audit questions answered from logs alone
• Analyst hours redirected from gathering information to judgment and analysis

Conclusion

Agentic AI will spread across every large organization, with or without a plan. The choice is whether it grows as a patchwork of disconnected, separately secured projects, or as a governed platform that reuses what the organization already owns and makes every agent accountable. By governing centrally, executing locally, and connecting existing systems through a federated MCP capability fabric, an organization can move faster with AI and stay in control of it, even on the most sensitive networks in the world.

Planning your own AI platform?

Whether you run a classified network or a growing business with sensitive data, the same principles apply. Take a look at our AI consulting and cloud architecture services, or request a free consultation.