The AI Agent Control Plane Is Becoming Enterprise Infrastructure

For much of the last two years, enterprise AI governance has focused on models: which models can be used, where data is processed, what information employees may submit, and whether generated outputs are trustworthy.

That was necessary. It is no longer sufficient.

The enterprise AI architecture now emerging is fundamentally different from the chatbot architecture that preceded it. Agents are increasingly able to authenticate, call APIs, query databases, interact with SaaS platforms, invoke tools and perform actions on behalf of users or autonomously.

At that point, the central security question changes.

It is no longer simply:

What is the AI allowed to know?

It becomes:

What is the AI allowed to do?

That distinction is pushing identity, authorization, policy enforcement, observability and lifecycle management into the centre of enterprise agent architecture.

And the timing matters. On 2 August 2026, enforcement powers under the EU AI Act began to apply, alongside new transparency requirements for certain AI systems. Europe has therefore entered a period in which AI governance is moving from policy preparation toward operational enforcement.

The result is a convergence between two previously separate disciplines: AI governance and infrastructure security.

Agents are becoming identities

Traditional software already has non-human identities.

Applications use service principals. Kubernetes workloads use service accounts. CI/CD systems use workload identities. Cloud automation receives IAM roles. Databases authenticate applications through managed identities, certificates or secrets.

AI agents appear to fit neatly into the same model.

They do not.

An ordinary application usually executes deterministic code against relatively predictable interfaces. An agent can dynamically decide which tool to use, construct requests at runtime, interpret results and choose its next action based on context.

That makes an agent identity qualitatively different from a conventional service identity.

Microsoft has responded by introducing first-class agent identities through Microsoft Entra Agent ID. Its architecture supports purpose-built agent identities, authentication and authorization controls, Conditional Access, identity protection and lifecycle governance. Microsoft also describes human sponsors responsible for agent identities and mechanisms for preventing orphaned agents when those sponsors leave an organisation.

This is an important architectural signal.

The industry is starting to treat agents not merely as applications using AI, but as a new category of actor inside enterprise identity systems.

Once that happens, the number of agents matters far less than the number of permissions, relationships and actions those agents can accumulate.

MCP exposes the real governance problem

Model Context Protocol has accelerated another part of this transition.

MCP provides a standard mechanism through which models and agents can discover and interact with tools such as databases, APIs, filesystems and enterprise services.

Standardisation is valuable because developers no longer need to create a completely different integration mechanism for every agent-tool combination.

But standardising tool execution does not automatically standardise governance.

Microsoft's own work on securing MCP makes this distinction explicit: MCP provides a common execution surface, but does not itself define the policy layer determining whether a particular tool call should be permitted. Microsoft has consequently been developing a governance layer intended to evaluate policy around agent tool execution.

This gets to the heart of the infrastructure problem.

Consider an agent that can:

• read customer records,

• create support tickets,

• send email,

• query financial data,

• modify cloud resources,

• execute database operations.

The model itself may be secure.

The MCP server may be functioning correctly.

Authentication may also succeed.

Yet the system can still be unsafe if the agent possesses combinations of permissions that allow unintended actions.

Authentication answers:

Who is this?

Authorization answers:

What may it access?

Agent governance needs to answer an additional question:

Should this specific action be allowed in this context, at this moment, with these inputs?

That requires a runtime control plane.

The control plane sits between reasoning and execution

A mature enterprise agent architecture will increasingly need a layer between an agent's decision and the system that executes it.

Conceptually:

User → Agent → Policy / Control Plane → Tool → Enterprise System

The control plane should not need to understand every detail of the model's internal reasoning.

Its job is simpler and more enforceable.

It should determine whether an action satisfies organisational policy.

For example:

An agent may have permission to query a production database, but only with read-only operations.

A financial agent may prepare payments, but transfers above a threshold require human approval.

A support agent may access customer information, but only when handling an active support case.

A cloud operations agent may restart workloads, but infrastructure deletion requires a change request.

An HR agent may retrieve employee information, but certain sensitive attributes may be excluded entirely.

This turns AI safety from an abstract model problem into something enterprise architects already recognise: policy enforcement around privileged operations.

Identity alone will not solve the problem

Agent identity is therefore necessary, but insufficient.

Giving every agent a unique identity improves attribution. It enables access policies, revocation, authentication logs and lifecycle controls.

But an authenticated identity can still make a dangerous request.

Microsoft's own Agent ID documentation acknowledges this problem. It limits some high-privilege roles and permissions because autonomous agents operating with excessive privileges could cause far-reaching changes such as modifying security configurations or administrative resources.

The same principle should apply beyond Microsoft environments.

Agent infrastructure will need several layers of control:

Identity
Every production agent should have a distinguishable non-human identity rather than sharing generic service credentials.

Least privilege
Agents should receive only the resources and operations required for their function.

Context-aware authorization
Permission to call a tool should not automatically mean permission to perform every operation exposed by that tool.

Policy enforcement
Sensitive actions should be evaluated independently of the model before execution.

Human approval
High-impact actions should support explicit approval checkpoints.

Auditability
Organisations need records showing which agent requested an action, under whose authority, against which resource and with what outcome.

Lifecycle management
Agents should have owners, expiration policies, access reviews and reliable revocation mechanisms.

This looks increasingly similar to privileged access management.

The difference is that the privileged actor may now be software capable of independently choosing its next action.

Network boundaries are returning to the AI architecture

There is another revealing development.

As agent systems become more autonomous, cloud providers are extending conventional network security mechanisms around them.

Google, for example, expanded VPC Service Controls in 2026 with capabilities specifically aimed at agentic workloads, emphasising network-level boundaries around the services and data that agents can reach.

This is significant because early generative AI architecture often concentrated heavily on application-layer safeguards: prompt filtering, content moderation and model policies.

Production agents force infrastructure controls back into the picture.

An agent may be manipulated through a prompt.

But the consequences of that manipulation depend largely on what infrastructure permits the agent to reach.

A compromised agent with no privileged connectivity is inconvenient.

A compromised agent connected to financial systems, production databases, identity management and infrastructure APIs is an incident.

Network segmentation, service boundaries and Zero Trust therefore remain highly relevant to agentic AI.

The technology changes.

The security principles do not.

AI governance is becoming an operational discipline

The regulatory environment reinforces the same direction.

From 2 August 2026, European Commission and Member State authorities began exercising enforcement responsibilities under the AI Act. General-purpose AI obligations are enforceable, while Article 50 transparency requirements also began applying to relevant systems.

Not every enterprise agent is automatically a high-risk AI system, and organisations should avoid treating the AI Act as a universal certification requirement for every internal automation.

But the broader direction is difficult to ignore.

Governance increasingly needs technical evidence.

Policies stating that AI is used responsibly will have limited value if an organisation cannot determine:

• which agents exist,

• who owns them,

• which identities they use,

• which systems they can reach,

• which permissions they hold,

• which models they depend on,

• which tools they can execute,

• and what actions they have actually performed.

That inventory problem alone may become substantial.

Microsoft already describes agent registries and central discovery as mechanisms for avoiding agent sprawl and shadow AI.

The parallel with cloud is obvious.

Enterprises first experimented with cloud workloads.

Then cloud usage expanded rapidly.

Eventually organisations needed landing zones, IAM standards, policy engines, cost governance, central logging and security baselines.

AI agents may follow the same path considerably faster.

The architecture that enterprises should start building

The practical priority is not to construct an enormous AI governance platform before deploying a single agent.

It is to establish a minimum production architecture before agents begin accumulating privileged access.

A reasonable starting point includes:

1. Agent inventory

Every production agent should be discoverable with an owner, purpose, environment, model, tools and business criticality.

2. Dedicated identity

Avoid shared secrets and shared application identities where possible. Each agent or agent class should be attributable.

3. Explicit tool permissions

An MCP server exposing ten tools does not imply that every agent should receive all ten.

4. Policy before execution

High-risk tool calls should pass through deterministic policy enforcement rather than relying on a prompt telling the model what not to do.

5. Approval boundaries

Define operations requiring human confirmation based on financial impact, data sensitivity, irreversibility or privilege.

6. Central telemetry

Agent decisions do not need to expose private chain-of-thought, but actions should be observable: identity, requested operation, target resource, policy decision, execution result and relevant correlation IDs.

7. Emergency revocation

Security teams must be able to disable an agent, blueprint, credential or access path quickly.

8. Periodic access review

Agent permissions should expire or be periodically reconfirmed rather than existing indefinitely.

None of these controls is particularly exotic.

What is new is the actor to which they must now be applied.

The next platform layer

Analysis

The agent market is currently dominated by models, frameworks and orchestration platforms because that is where most development activity is visible.

Enterprise adoption will shift attention downward.

Once agents control business processes, infrastructure teams will care less about whether an application uses one agent framework or another and more about whether the organisation has a reliable mechanism for identity, authorization, execution policy, audit and revocation.

That layer could become one of the most important pieces of enterprise AI infrastructure.

The winners may not necessarily be companies that build another agent framework.

They may be the organisations that solve the less glamorous problem of controlling thousands of machine actors interacting with thousands of enterprise resources.

Prediction

Over the next several years, enterprise architecture is likely to develop an agent control plane in much the same way cloud computing developed management planes, identity layers and policy engines.

It may not exist as a single product.

Parts will sit in IAM platforms.

Parts will exist in API gateways and MCP gateways.

Parts will live in cloud networking.

Parts will appear in agent registries, SIEM platforms, observability systems and policy engines.

But architecturally they will serve the same purpose:

separating an agent's ability to reason from its authority to act.

Conclusion

The transition from generative AI to agentic systems is not primarily a transition from better models to smarter applications.

It is a transition from software that produces information to software that can exercise authority.

That changes the infrastructure requirements.

Models still matter. Prompt security still matters. Data governance still matters.

But once agents can authenticate, retrieve privileged information, invoke tools and change external systems, the enterprise security boundary moves closer to execution.

The important architecture is therefore emerging between the agent and the systems it controls.

Identity tells us which agent is acting.

Observability tells us what happened.

The control plane determines whether it should be allowed to happen at all.

That may become the defining infrastructure problem of enterprise AI.