Notifications
Clear all
Topic starter
10/06/2026 10:58 pm
TL;DR: Agents are moving from pilots to production, but IAM models built for human sessions cannot reliably govern continuous tool use, delegated actions, and runtime decision paths, according to Cerbos' EIC 2026 analysis. The real control question is no longer inventorying agents first, but deciding what actions they may take at the point where money, data, or production state can move.
NHIMG editorial — based on content published by Cerbos: EIC 2026 analysis of AI agent authorization, delegation, and runtime policy
Questions worth separating out
Q: How should security teams govern AI agent actions at runtime?
A: Security teams should evaluate each consequential action at the point of execution, not only at authentication or provisioning time.
Q: Why do AI agents complicate traditional IAM and PAM controls?
A: AI agents complicate traditional IAM and PAM controls because those models assume stable entitlements and human-paced review cycles.
Q: What breaks when an agent uses a human credential for delegated work?
A: What breaks is accountability.
Practitioner guidance
- Map the vaults first Identify the tools, APIs, data stores, workflows, credentials, and transactions where an agent action can create real harm.
- Preserve delegation at every hop Use token exchange or equivalent claims propagation so each downstream service can see the actor chain, audience, and delegated authority.
- Move policy evaluation into the runtime path Evaluate access where the action becomes real, whether that is a gateway, MCP server, application service, or data layer.
What's in the full article
Cerbos' full analysis covers the operational detail this post intentionally leaves for the source:
- Runtime policy placement across gateways, MCP servers, application services, and data layers
- Decision log design for reconstructing agent actions with policy basis and context
- Delegation patterns using token exchange and actor claims across service hops
- Practical examples of where authorization should happen when an agent reaches a vault
👉 Read Cerbos' analysis of AI agent authorization and runtime policy →
Agent authorization and vault controls: are your IAM controls ready?
Explore further
12/06/2026 4:43 am
Agent authorization is now the vault problem, not the inventory problem. Identity still matters, but identity only gets the agent into the building. The decisive question is whether the system can stop or permit a concrete action when that action reaches money movement, data exposure, or production change. That is where conventional IAM loses leverage and where authorization must move to the exact control point. Practitioner conclusion: re-centre governance on the action that can cause harm, not the label attached to the actor.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: Who should be accountable when agentic automation causes a security event?
A: Accountability should sit with the organisation that defined the delegation boundary, the policy owner who approved the runtime action, and the system owner who exposed the tool or workflow. If those roles are not explicit, agentic systems create shared responsibility gaps that look like technical problems but are really governance failures.
👉 Read our full editorial: Agent authorization for AI systems: what IAM teams must protect
