Identity-aware access is the missing layer in agentic security

At a glance

What this is: This is an analysis of why agentic security still fails when identity-aware access is missing, and the key finding is that downstream services need per-request verification, not just better sandboxing.

Why it matters: It matters because IAM teams, NHI owners, and platform architects must govern agent access at the service boundary, where identity, scope, and auditability determine blast radius across autonomous, workload, and human access paths.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Pomerium's analysis of identity-aware access for agentic security

Context

Identity-aware access for AI agents means every downstream service verifies the caller, its scope, and its delegated authority on each request. The problem is that monolithic agent designs still combine reasoning, tool use, and secrets in one runtime, which makes the trust boundary too wide for conventional IAM and network controls to contain.

For NHI programmes, the issue is not whether an agent can call a tool. It is whether the service receiving that call can distinguish legitimate delegated access from a compromised request path, enforce least privilege in context, and keep an audit trail that survives across hops and services.

Key questions

Q: How should security teams control AI agent access to internal services?

A: Security teams should control AI agent access at the service boundary, not only inside the agent runtime. The right model is per-request verification, individually attributable identity, and policy that checks the delegated task before the request is allowed. That approach reduces blast radius and preserves auditability when an agent is compromised.

Q: Why do shared service accounts create risk for AI agents?

A: Shared service accounts hide which agent made a request, so they collapse accountability and make incident response slower. They also turn credential exposure into a single compromise path for multiple workloads. For agentic systems, every identity should be attributable to a specific workload or delegated task.

Q: What breaks when AI agents are trusted only at the sandbox layer?

A: What breaks is downstream authorisation. A sandbox can limit local execution, but it does not force the receiving application to verify the caller’s identity, scope, or intent. If the service accepts the request without re-evaluating context, a compromised agent can still use legitimate-looking access to move through internal systems.

Q: Who should own AI agent identity governance in an enterprise?

A: AI agent identity governance should sit jointly with IAM, platform security, and application owners because the risk crosses the runtime, the proxy, and the receiving service. No single team can see the whole delegation chain unless identity context is preserved end to end.

Technical breakdown

Monolithic agent design and trust boundary collapse

A monolithic agent keeps reasoning, execution, and credential storage inside the same process or memory space. That creates a trust boundary violation because any prompt injection, tool abuse, or runtime compromise can reach the same secrets the agent uses to act. The architectural flaw is not the model itself, but the lack of separation between decision-making and credential-bearing execution. In zero trust terms, the agent becomes both the requester and the bearer of authority, which weakens containment and makes exfiltration a single-hop problem.

Practical implication: separate credential custody from agent execution so a compromised runtime cannot automatically inherit standing access.

Identity-aware access proxying for downstream services

An identity-aware access proxy sits between the agent and the service it wants to reach, forcing each request to carry verifiable identity context. That changes the control point from the agent’s internal sandbox to the service boundary, where policy can evaluate who the caller is, what task it is performing, and whether the request fits the delegated scope. This is different from endpoint filtering alone because it makes authorisation request-specific rather than environment-specific, which is the right model for dynamic agent behaviour.

Practical implication: enforce per-request policy at the proxy layer so downstream applications can deny out-of-scope agent actions without relying on the agent to self-restrict.

Audit trails and identity propagation across service chains

Agentic systems rarely stop at one service call. A single agent may call Service A, which calls Service B, which triggers Service C, and accountability breaks unless identity context follows the chain. Identity propagation preserves who the agent is and under which delegated authority each hop occurred. That matters for forensic review, compliance evidence, and blast-radius analysis because logs without caller context cannot reconstruct whether an action was permitted, excessive, or malicious.

Practical implication: require identity propagation and immutable logging across every service hop so investigation teams can reconstruct the full delegation chain.

Threat narrative

Attacker objective: The attacker aims to turn a trusted agent runtime into a credential exfiltration and downstream action channel that can be used to breach internal services.

1. Entry begins when an attacker influences the agent through prompt injection or another untrusted input path, causing the agent to process hostile instructions inside its own runtime.
2. Credential access occurs because the monolithic agent keeps reasoning, execution, and secrets together, so the attacker can reach OAuth tokens or other stored credentials from the same process boundary.
3. Impact follows when the agent uses those credentials to call downstream services with legitimate-looking requests that expand access, expose sensitive data, or trigger unauthorised actions at scale.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Identity-aware access is the missing control plane for agentic workloads. The article is right to separate sandbox hardening from service-boundary enforcement. AI agents do not become safer merely because their local runtime is constrained if downstream systems still accept requests without strong caller identity and scope verification. The governance problem is now distributed across the agent, the proxy, and the receiving service, which means IAM teams must treat agent access as a live authorisation event, not a static deployment attribute. Practitioners should re-centre control ownership around the service boundary.

Shared service accounts are the wrong default for agentic access. The article cites survey data showing that many organisations still place AI agents behind shared accounts, which erases accountability and turns every call into an attribution problem. That pattern belongs to an era when machine access was treated as infrastructure plumbing, not an independently acting identity surface. The implication is that agent identity must be individually attributable, policy-scoped, and auditable or else access governance collapses into shared secret management.

Per-request verification should become the baseline assumption for NHI and autonomous systems. Static trust models assume the access context is stable enough to be reviewed later, but agentic systems can acquire, use, and discard authority in very short bursts. The key concept here is identity blast radius: how far an agent can move when a single request is accepted without re-evaluating identity, scope, and intent. Practitioners should measure the distance between one accepted request and the next boundary failure.

Zero trust for agents is not a sandbox problem alone. Anthropic-style separation and Nvidia-style enforcement each reduce risk, but neither fully closes the inter-service trust gap. That gap is where governance breaks in production because the downstream application still needs to know whether the caller is legitimate at the moment of use. The field should stop treating agent security as an execution-environment issue and start treating it as a continuous authorisation problem across every service hop.

Assumption collapse: access review processes were designed for privileges that persist long enough to be observed, logged, and recertified. That assumption fails when an agentic system can acquire and use authority inside a short-lived session, then move on before review cycles can capture the state. The implication is that governance models built around periodic review no longer describe the real risk window for autonomous or semi-autonomous access.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 77% of secrets leaks incidents resulted in tangible damage in our NHI research, which is why privilege scope and credential handling cannot be separated from agent governance.
• For a broader baseline on machine identity exposure, review 52 NHI Breaches Analysis and compare the failure patterns against your agent access paths.

What this signals

Identity blast radius is now the most useful way to think about agent security programmes. If a request can traverse multiple services before identity is revalidated, the programme is not enforcing zero trust at the point that matters. Teams should expect pressure to move from container-only controls to proxy-enforced authorisation and hop-by-hop auditability.

The operational signal is that access governance will increasingly be judged by whether it can separate workload identity from execution context. Organisations that still rely on shared tokens, inherited permissions, or opaque service-to-service trust will find agent deployments difficult to audit and harder to contain. That shift affects NHI, autonomous, and human access patterns alike when delegation chains are involved.

For practitioners

• Map the agent trust boundary Document where reasoning ends, where credentials live, and where downstream services first see the request so you can identify the real control point.
• Remove shared accounts from agent paths Replace shared service accounts with individually attributable identities for each agent, workflow, or delegated workload so accountability remains intact.
• Enforce per-request policy at the proxy Put identity-aware policy between the agent and the service so every call is evaluated for caller identity, task scope, and delegated authority.
• Propagate identity through service chains Carry identity context across each hop, including internal API calls, so logs preserve the full delegation chain for response and investigation.

Key takeaways

• AI agent risk is not just about model behaviour, it is about whether identity is enforced where the request is actually consumed.
• The scale of the problem is already visible in NHI data, where excessive privilege and weak auditing continue to widen blast radius.
• Practitioners should move governance to the service boundary, because per-request identity verification is what makes agent access defensible.

Key terms

• Identity-aware access proxy: A policy enforcement layer that sits between a caller and a downstream service, verifying identity and context before allowing each request. In agentic environments, it prevents the agent runtime from becoming the only trust decision point and gives security teams control over delegated access.
• Identity blast radius: The amount of access a compromised identity can use before a control boundary stops it. For AI agents, this is measured by how far a single accepted request can travel across services, data, and tools before identity is rechecked and scope is enforced.
• Service account sprawl: The uncontrolled growth of shared or poorly attributed machine identities across applications, automation, and agent workflows. It usually appears when teams reuse credentials for convenience, which erases accountability and makes access review and incident response much harder.

Deepen your knowledge

Identity-aware access for AI agents is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for agentic workloads, the course helps connect runtime behaviour to governance decisions.

This post draws on content published by Pomerium: Why identity-aware access is the missing layer in agentic security. Read the original.