AI infrastructure needs identity controls that preserve interoperability

At a glance

What this is: This is Stacklok’s analysis of how AI infrastructure is forcing enterprises to rethink identity, access, and interoperability for agents and knowledge workers.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent access patterns that are faster, broader, and harder to review than human workflows.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Stacklok's analysis of AI infrastructure identity and agent governance

Context

AI infrastructure governance is becoming an identity problem before it becomes a model problem. Once agents can reach internal systems, the real question is not whether they can generate useful output, but whether they can be constrained, observed, and revoked with the same discipline enterprises expect from human and machine identities.

Stacklok’s discussion treats interoperability, protocol boundaries, and transaction context as the missing control layer for AI systems. That aligns closely with the broader NHI problem: once a non-human actor can touch data, call tools, and chain actions, access must be scoped to the task, not assumed from the environment.

The article’s cloud-native comparison is apt. Kubernetes-era lessons about open standards, portability, and reconciliation are now resurfacing in AI infrastructure, but the identity layer is less mature than the tooling layer. That is the gap identity teams need to close first.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents complicate least-privilege design?

A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent. The system may need broad enough access to complete a task, but that same access can overshoot if scope is not tightly controlled. The fix is task-scoped authorisation with clear boundaries, not wider standing access.

Q: How do organisations avoid lock-in in AI infrastructure and identity controls?

A: Prefer open protocols, portable identity layers, and policy enforcement points that sit between agents and upstream systems. That gives the enterprise room to change models or tools without rebuilding the trust boundary every time the stack changes.

Q: What should teams do first when agent access starts reaching production systems?

A: Start by reducing blast radius. Put the agent in an isolated environment, remove unnecessary write access, define clear ownership, and require evidence before expanding permissions. The goal is to make the workflow observable and revocable before it becomes business-critical.

Technical breakdown

Why MCP changes the access boundary for AI agents

Model Context Protocol creates a formal boundary between an agent and the systems it can reach. That matters because the protocol is not just an integration convenience. It defines where tool invocation is mediated, how context is passed, and how access can be narrowed without breaking the workflow. In practice, MCP can become the control point where identity, authorization, and data minimization intersect, especially when agents are allowed to read from multiple systems but should not exfiltrate beyond the task context.

Practical implication: treat MCP endpoints as governed access surfaces, not just developer plumbing.

Why transaction tokens matter in agent-to-system chains

A transaction token carries context about the request, the user, and the permitted scope through the agent path. Without that token, downstream services only see a generic non-human caller, which makes it harder to enforce customer-specific filtering, task scoping, and data minimisation. This is especially important when an agent acts on behalf of a human, because the caller and the beneficiary are not the same thing. The control problem is provenance across the chain, not authentication alone.

Practical implication: propagate task and subject context end to end so downstream systems can apply meaningful access decisions.

Why least privilege gets harder when agents are the operator

Least privilege for agents is not a static provisioning exercise. The right permission set depends on how much the agent is allowed to discover, combine, and reuse during runtime. That makes coarse-grain containment important at the start: isolated execution, read-only access where possible, and strict egress controls. As the agent becomes more useful, the privilege model has to stay aligned with actual task scope rather than expanding because the workflow is convenient.

Practical implication: govern agent privileges as session-scoped operational boundaries, not as one-time setup decisions.

Threat narrative

Attacker objective: The objective is to abuse agent connectivity to reach sensitive data or internal systems beyond the intended task boundary.

1. Entry occurs when an AI agent is connected to internal tools through a broad interface that was designed for convenience rather than task-scoped control.
2. Escalation happens when the agent can chain tool calls, reuse context, or access additional systems without a transaction token carrying the original request constraints.
3. Impact follows when the agent can read or move data beyond its intended purpose, creating overbroad access and data egress risk across internal systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Interoperability is now an identity control requirement, not a platform preference. The article’s Kubernetes comparison is really about who owns the trust boundary when agents access enterprise systems. Open protocols matter because they let identity teams govern access without hard-coding a single vendor stack into the control plane. The practitioner conclusion is that portability and enforceable boundaries now belong in the identity architecture discussion, not just the platform roadmap.

Transaction context is the missing layer in agent governance. Traditional IAM can authenticate a caller, but it does not always preserve who the agent is acting for, what task it is executing, or how far the request may propagate. That is why transaction tokens are so important: they carry intent and scope through the chain. The practitioner conclusion is that identity governance has to move from login events to request provenance.

Least privilege for agents is a runtime problem, not a provisioning problem. The article describes a world where useful work emerges through iteration and tool chaining, which means privilege cannot be assumed stable for the whole session. That assumption fails because an agent’s effective reach can change mid-task as it discovers new paths. The practitioner conclusion is that static permission design will not be enough to govern agent behaviour.

Trust optimisation is really about reducing the blast radius of useful automation. The article’s focus on isolation, read-only access, and egress control is more important than the performance narrative around speed. Those controls do not eliminate risk, but they keep agent productivity within a governable envelope while identity teams build stronger policy layers. The practitioner conclusion is to measure how much damage an agent can do before asking how much work it can complete.

AI infrastructure is converging on a new identity operating model. Developers are the early proving ground, but the governance pattern will extend into knowledge work, support, and business operations. That means lifecycle control, access review, and delegated accountability will have to work across humans, NHIs, and AI agents together. The practitioner conclusion is that identity programmes should prepare for mixed actor estates rather than treating AI as a separate silo.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• The same survey found that only 13% of organisations feel extremely prepared for the reality of agentic AI, which helps explain why governance lags deployment.
• For a broader framework on the underlying risk model, see OWASP Agentic AI Top 10.

What this signals

Identity teams should expect AI infrastructure governance to move from integration review to runtime control. The article shows that agents are no longer a lab concept. They are becoming a practical access path into enterprise systems, which means the next control gap will be provenance, not authentication. The useful question is whether your current IAM and PAM processes can still explain who or what is acting when the workflow becomes agent-mediated.

Transaction context is the right named concept for the next phase of agent governance. It describes the need to preserve request intent, subject identity, and permitted scope across every hop from interface to tool to data source. Without it, downstream systems only see a generic caller and the programme loses the ability to apply meaningful control. That is a design issue for the identity architecture, not a training issue for users.

Many organisations are already over-granting AI access, with 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey. That means the governance backlog is structural, and teams should prioritise containment and reviewability before they scale agent coverage further.

For practitioners

• Map agent access paths end to end Document every system, tool, and data source an agent can reach, then identify where identity context is lost between the caller and downstream services. Prioritise paths where the agent can cross trust boundaries without a transaction token or equivalent request provenance.
• Constrain agent privileges at the boundary Start with isolated execution, read-only access, and explicit egress controls for new agent workflows. Expand permissions only after the workflow proves it needs the access and the business owner can justify the scope.
• Treat MCP endpoints as governed access surfaces Apply policy, logging, and review to every protocol endpoint that can invoke tools or retrieve context. Use the same scrutiny you would apply to a privileged integration because MCP can become the enforcement point for agent identity and authorization.
• Build reviewable accountability for agent actions Assign ownership for each agent workflow, define what evidence must exist for approval, and specify how changes are revoked when the workflow drifts. This keeps agent behaviour tied to an accountable business process instead of an anonymous automation path.

Key takeaways

• AI infrastructure is becoming an identity governance problem because agents now need access, context, and revocation controls, not just model access.
• The clearest risk signal is over-granted access, and the article’s core lesson is that portability and interoperability only matter if the boundary is enforceable.
• Practitioners should focus on transaction context, blast radius, and reviewable ownership before scaling agent workflows into production.

Key terms

• Transaction token: A short-lived credential that encodes a specific user-authorised action set for a limited time. It is narrower than a general access token because it is intended to constrain an agent to a particular task, context, or workflow rather than to broad account access.
• Selective Permeability: Selective permeability is the design pattern of letting useful data and actions pass between systems while blocking unsafe movement. In AI infrastructure, it describes a controlled boundary that allows an agent to work with internal systems without turning every integration into full trust.
• Agent Identity Blast Radius: Agent identity blast radius is the amount of damage an autonomous agent can cause if its credentials, permissions, or decision logic are abused. The larger the blast radius, the more a single compromised agent can affect data, systems, and downstream workflows across the enterprise.

What's in the full article

Stacklok's full blog post covers the operational detail this analysis intentionally leaves for the source:

• How the team thinks about MCP as a protocol boundary for AI-native applications and enterprise tool access
• The role of LLM gateways in cost control, model routing, and sensitive data egress management
• Why transaction tokens need to persist across agents, interfaces, and downstream systems
• How developers, knowledge workers, and infrastructure teams may adopt different trust thresholds for agent access

👉 Stacklok's full blog post covers the cloud-native lessons, MCP role, and transaction-token context in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.