AI infrastructure needs identity controls that preserve interoperability

At a glance

What this is: This is Stacklok’s analysis of why AI infrastructure needs identity controls, transaction context, and interoperable guardrails rather than vertically integrated lock-in.

Why it matters: IAM, NHI, and AI governance teams need this lens because agent access decisions now span tools, data, and model providers, and control points must survive platform change.

Context

Enterprise AI is colliding with an identity gap that cloud-native teams already learned to solve: who or what is acting, what it may touch, and how to preserve control when the stack changes. In this article, Stacklok argues that AI infrastructure needs identity controls that work across agents, gateways, and downstream systems without forcing a single vendor path.

The core governance problem is interoperability. Enterprises want guardrails that limit access and data egress, but they also want the freedom to switch models, tools, and platforms as the market shifts. That makes identity and transaction context part of the infrastructure design, not an afterthought.

For IAM and NHI practitioners, the important point is that this is not just an AI architecture question. It is a lifecycle and access-control question for non-human actors that need to be authenticated, authorized, observed, and contained across a changing execution path.

Key questions

Q: How should security teams govern AI workflows that use multiple tools and data sources?

A: Security teams should govern AI workflows by placing explicit authorization at each decision point, not by relying on the permissions attached to the surrounding application or service account. The practical goal is to scope read, retrieve, and execute access separately so the workflow cannot inherit broader reach than it needs for the task.

Q: Why do AI agents increase access risk compared with traditional application integrations?

A: AI agents can make runtime decisions, chain tool calls, and reach multiple systems faster than a human operator. That expands the blast radius if identity controls are weak. Risk rises when credentials are reused, permissions are excessive, or session boundaries are unclear, because one compromised agent identity can touch data, APIs, and downstream workflows.

Q: What breaks when transaction context is lost in an agent workflow?

A: When transaction context is lost, downstream systems can no longer tell whether the request is still specific, valid, and constrained. That is where over-disclosure, overbroad actions, and unsafe data movement begin. The control failure is not the model output itself, but the inability to bind access to the original purpose.

Q: What should teams do when AI infrastructure starts to look too vertically integrated?

A: Teams should check whether the stack is locking identity, policy, and data paths to one vendor’s model or gateway choices. If portability disappears, governance becomes harder to maintain during migrations, and the organisation loses leverage over access boundaries. The practical test is whether controls survive a platform swap without redesign.

Technical breakdown

Why AI infrastructure needs identity-aware guardrails

AI agents do not behave like traditional application workloads because their access pattern changes as context changes. A useful agent may need to call multiple tools, pass through gateways, and touch sensitive systems in a single workflow. That makes identity controls more than simple authentication. They need to carry transaction context so downstream systems can decide whether the request is still valid, not just whether the actor once logged in. In practice, this is the difference between static access and governed execution across the full agent path.

Practical implication: treat agent identity, authorization, and transaction context as one control plane rather than separate implementation layers.

How MCP changes the control boundary for agents

Model Context Protocol, or MCP, creates a formal interface between an agent and the tools it can reach. That matters because it moves control from ad hoc integration to a recognizable access membrane. Instead of every agent speaking directly to every system, the protocol can define where access begins, what context must be preserved, and which actions remain visible to governance. The security value is not the protocol itself, but the fact that the access path becomes easier to constrain, inspect, and reason about. This is especially important when humans cannot reliably review every tool call in real time.

Practical implication: use MCP as an enforcement boundary, then bind policy, telemetry, and approval logic to that boundary.

Why transaction tokens matter more than model quality

The article’s most important control point is not the model output but the transaction itself. If an AI-empowered worker or agent interacts with customer data, the system needs proof that the request is tied to a live, specific transaction and that downstream systems can preserve that context. Without that, the agent may inherit broad access that was never intended for the exact request being made. This is a familiar IAM lesson in a new form: authorization that is not transaction-bound will over-disclose as soon as the workflow crosses systems.

Practical implication: require transaction-scoped controls for sensitive workflows instead of relying on broad agent entitlements.

Threat narrative

Attacker objective: The objective is to turn agent access into uncontrolled data movement or unsafe system actions by exploiting weak identity boundaries.

1. Entry occurs when an agent receives access to tools and data through loosely governed integrations rather than a controlled identity boundary.
2. Escalation happens as the agent moves from one system to another without preserving transaction context, allowing scope to expand beyond the original request.
3. Impact follows when sensitive data egress or overbroad tool access cannot be contained across the full agent path.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI infrastructure is now an identity architecture problem, not just an application design problem. The article shows that enterprises are no longer experimenting with isolated copilots. They are putting agents into real workflows that cross internal systems, gateways, and data stores. That means the question is no longer whether AI works, but whether the identity model can preserve control as the workflow moves.

Interoperability is becoming a security requirement, not a preference. Vertical integration may simplify the first deployment, but it increases dependency on a single vendor’s access and policy model. Enterprises that want optionality need guardrails that survive model change, tool replacement, and platform migration. The practitioner conclusion is that portability and security now rise or fall together.

Transaction context is the missing control plane for AI-era access. Traditional IAM often assumes a stable subject and a durable session. That assumption weakens when an agent carries work across multiple systems on behalf of a user or team. The implication is that authorisation must increasingly follow the transaction, not just the account.

AI infrastructure is creating an identity blast radius problem. Once agents are allowed to reach multiple systems, the blast radius is defined by how far identity context can travel without being lost or diluted. That is a governance problem for IAM, NHI, and platform teams together. Practitioners should treat every uncoupled tool hop as a potential loss of control.

Controlled openness is the right design goal for enterprise AI. The article’s strongest signal is that the market will reward platforms that expose enough interoperability to avoid lock-in while still enforcing access boundaries, telemetry, and egress limits. The right question is not whether to centralise everything, but where to place enforceable boundaries that preserve choice and accountability.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Identity context must travel with the work: AI programmes will fail if they treat authentication as a front-door event and ignore the rest of the workflow. The operating model has to preserve subject, purpose, and scope as the agent moves across tools, gateways, and data stores.

Interoperability is a control requirement: enterprises should resist designs that make policy enforcement depend on one AI stack. Once identity, policy, and egress are portable, platform choice becomes a governance decision rather than a containment risk.

For practitioners

• Define the agent identity boundary Map exactly where an agent is authenticated, where it is authorised, and where transaction context must persist across tool calls and downstream systems.
• Constrain tool access by workflow Limit each agent to the smallest practical tool set for the task, then separate read-only access from any action that can modify data or trigger side effects.
• Preserve data egress controls across the path Apply policy at the gateway, the agent runtime, and the destination system so that sensitive data cannot leave the approved workflow through a weaker hop.
• Design for platform portability Avoid binding core identity and policy logic to a single AI stack so that model, tool, or gateway changes do not force a governance redesign.

Key takeaways

• AI infrastructure introduces a governance problem that looks like IAM, but behaves more like transaction control across non-human actors.
• The article’s central warning is that single-stack convenience can harden into lock-in if identity and egress controls are not portable.
• Practitioners should design for identity context, tool containment, and policy portability before agent deployments expand beyond developer workflows.

Key terms

• Transaction Context Review: Transaction context review is the practice of evaluating the surrounding signals for a payment or transfer, including identity, device, history and behavioural factors. It is more effective than static rule checks because it looks at how a transfer fits the broader risk pattern.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Interoperable Guardrails: Interoperable guardrails are policy and control mechanisms that continue to work when models, gateways, or tools change. They preserve enforcement, visibility, and containment across different vendors and stacks instead of depending on one integrated platform.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.