Notifications
Clear all
Topic starter
10/06/2026 12:10 am
TL;DR: A monolithic AI agent pattern that mixes reasoning, execution, and credentials in one process creates a credential exfiltration risk that zero trust tooling was not built to absorb, according to Pomerium’s analysis of recent agent security research. The real gap is per-request identity verification and policy enforcement at the downstream service boundary, not just sandbox hardening.
NHIMG editorial — based on content published by Pomerium: Why identity-aware access is the missing layer in agentic security
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.
Questions worth separating out
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.
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.
Q: What breaks when AI agents are trusted only at the sandbox layer?
A: What breaks is downstream authorisation.
Practitioner guidance
- 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.
What's in the full article
Pomerium's full blog covers the operational detail this post intentionally leaves for the source:
- How the identity-aware access proxy enforces per-request policy for downstream services
- How identity propagation and audit logging work across multi-hop agent request chains
- How the architecture fits alongside managed agents and sandbox enforcement without replacing them
👉 Read Pomerium's analysis of identity-aware access for agentic security →
AI agent identity risk: what IAM teams are missing?
Explore further
11/06/2026 1:51 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-aware access is the missing layer in agentic security
12/06/2026 3:26 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-aware access is the missing layer in agentic security
