Who is accountable when an AI endpoint exposes IAM tokens through metadata access?

Accountability usually sits with both the platform owner and the team operating the workload identity. The platform owner must prevent unsafe request paths, while the service owner must constrain permissions, egress, and metadata access. Frameworks such as NIST SP 800-53 and zero trust architecture place that responsibility on control owners, not on attackers.

Why This Matters for Security Teams

When an AI endpoint can reach instance metadata, the problem is rarely the model itself. The real exposure is that the workload can retrieve IAM tokens and then act with whatever permissions those tokens carry. That turns a routine integration issue into a privilege boundary failure. The control question is not whether an attacker is clever, but whether the platform and workload owners have prevented token discovery paths that should never have existed.

This is why NHI governance has to treat metadata access as a high-risk trust path, not a convenience feature. The OWASP Non-Human Identity Top 10 calls out the operational risk created when service identities are over-privileged or poorly constrained, and NHIMG research on the 2024 Non-Human Identity Security Report shows that only 19.6% of security professionals are strongly confident in managing workload identities securely. In practice, many security teams encounter token exposure only after an AI workload has already used the metadata path to harvest credentials and move laterally.

How It Works in Practice

Accountability in this scenario is shared, but the responsibilities are different. The platform owner is accountable for the cloud and runtime controls that make token theft possible, including metadata endpoint exposure, network segmentation, and default instance permissions. The service owner is accountable for the workload identity itself, including least privilege, token lifetime, egress restrictions, and safe handling of any secrets or federated credentials the AI endpoint can access.

Operationally, the strongest pattern is to remove standing trust wherever possible. That means blocking direct access to the metadata service unless the workload truly needs it, using workload identity primitives such as SPIFFE or OIDC-bound identities, and issuing short-lived credentials only for the task being performed. If the agent needs to call downstream APIs, use policy-as-code at request time so the authorization decision reflects context, not a static role assumption. This aligns with current guidance from NIST SP 800-53 Rev. 5 Security and Privacy Controls and the control expectations discussed in NHIMG analysis of the Salesloft OAuth token breach, where token misuse became the real security event rather than the initial access path.

• Disable or tightly scope metadata access for AI workloads unless there is a documented business need.
• Prefer ephemeral, task-scoped credentials over long-lived instance profiles or shared service accounts.
• Constrain egress so a compromised endpoint cannot freely exfiltrate tokens or call arbitrary control-plane services.
• Use runtime authorization and logging to detect when a model or agent requests actions outside expected context.

These controls tend to break down in legacy VM estates and Kubernetes clusters that still depend on broad node roles, open metadata routes, or shared secrets injected at deploy time.

Common Variations and Edge Cases

Tighter metadata restrictions often increase deployment complexity, so organisations have to balance stronger isolation against operational friction. Best practice is evolving for AI agents that need cloud access, and there is no universal standard for every runtime yet.

One common edge case is a managed platform where the cloud provider exposes metadata by default and the application team cannot change the host settings. In that case, accountability does not disappear. The platform owner still owns the safe-by-default runtime, while the service owner must ensure the endpoint cannot exploit the exposed path through overly broad roles or outbound connectivity. Another variation is agentic systems that chain tools across services. Here, a single exposed token can become a pivot into email, storage, CI/CD, or customer data if permissions were designed for humans rather than autonomous workloads.

NHIMG’s Guide to the Secret Sprawl Challenge and the 52 NHI Breaches Analysis both reinforce the same lesson: hidden trust paths and overexposed secrets are usually what turn a configuration issue into a breach. For AI endpoints, accountability should therefore be assigned at the control owner level, not blamed on the model, because the model only exploits the access path that was left open.

Related resources from NHI Mgmt Group

• Who is accountable when an endpoint management breach exposes privileged access?
• Who is accountable when an AI platform exposes data and behavioural controls through backend flaws?
• Who is accountable when a collaboration workspace exposes CUI through excessive access?
• Who is accountable when an AI agent causes production access through a trusted proxy?