Continuous authorization for AI agents needs a new reference model

At a glance

What this is: This is a reference architecture for continuous authorization of AI agents, built to replace human-session IAM assumptions with per-action identity, context, enforcement, and audit.

Why it matters: It matters because IAM, IGA, and PAM teams now have to govern non-human decision-making at runtime, where static roles and login-time trust no longer describe actual risk.

Context

Enterprises are trying to govern AI agents with identity patterns that were designed for people, not workloads that decide and act at runtime. The resulting gap is not cosmetic: session-based trust, static role binding, and login-time authorization all assume predictable human behaviour.

The article argues that continuous authorization has to be built as a reference architecture, not a point feature. That makes the identity question central to AI governance, because the control boundary now moves from the login event to each discrete action the agent takes.

Key questions

Q: What breaks when AI agents are governed only with login-based IAM?

A: Login-based IAM breaks because it stops at authentication and never evaluates the thousands of actions an autonomous agent may take after sign-in. The result is broad delegated access with no runtime control, which makes inherited credentials, token reuse, and chained actions effectively invisible to governance teams. Runtime authorisation is the missing control plane.

Q: Why do AI agent authorisation models need continuous decisioning?

A: Because the risk changes with each action. An agent may read harmless data in one step, invoke a sensitive tool in the next, and write to a regulated system after that. Continuous decisioning lets the policy engine re-evaluate context, delegation, and sensitivity before each action instead of assuming the earlier decision is still valid.

Q: What are the signs that AI agent authorization is failing?

A: Watch for agents reaching systems outside their intended task, holding broad permissions after the job changes, or producing incomplete audit trails for sensitive actions. If compliance, security, and operations teams cannot reconstruct why an action was allowed, the authorization model is already too weak for governance.

Q: What should security teams do when policy checks exist only at the API gateway?

A: They should treat that as partial coverage, not control. Gateways do not see every data-layer operation, internal agent-to-agent call, or runtime tool invocation, so a single enforcement point leaves real paths outside policy. The governance question is whether every domain that an agent can touch produces the same allow, deny, or escalate decision.

Technical breakdown

Why session-based IAM breaks for AI agent authorisation

Human IAM was built around a session that can be authenticated once and trusted for a period of time. AI agents do not behave that way: they may issue thousands of actions per minute, each with different resource sensitivity and risk. A login-time decision therefore says little about the safety of later actions. In practice, static tokens, long-lived API keys, and role binding create a false sense of control because the real authorisation problem sits at the action layer, not the access-event layer.

Practical implication: move authorisation decisions from session start to every agent action that can affect data, tools, or infrastructure.

What continuous authorisation needs beyond policy rules

A policy engine alone cannot govern agentic access unless it also knows who is asking, what context surrounds the request, and how much autonomy the workload has. That is why the architecture adds identity assertion, context assembly, and autonomy metadata before policy evaluation. Without those inputs, policy becomes blind to delegation chains, runtime tool use, and task-specific scope changes. The result is not just weaker control, but weakly explained control that is hard to defend in audit or incident review.

Practical implication: define the identity and context inputs that must exist before any per-action policy can return allow or deny.

How enforcement across applications, infrastructure, data, and AI workloads works

Agentic workflows rarely stay in one control plane. A single task can cross APIs, cloud permissions, databases, and agent-to-agent tool calls, which means enforcement must follow the action across all four domains. If only the gateway is checked, direct data access, internal calls, and MCP tool invocations can slip through uncoupled paths. The architecture treats each domain as part of one decision path, so the policy result is enforced where the action actually lands, not where it originated.

Practical implication: map each agent workflow to every enforcement point it can traverse and close any domain that lacks a real decision check.

Threat narrative

Attacker objective: Convert a trusted agent runtime into broad, persistent operational reach across sensitive data and infrastructure.

1. Entry begins when an agent is provisioned into production through a long-lived credential or shared workload identity rather than a dedicated, verifiable identity. That starting point gives the workload access without a clear chain of custody.
2. Escalation occurs when the agent is allowed to keep acting after the initial authentication event, even as it touches different resources, tools, and delegation paths with changing risk. The trust decision is made once, but the workload keeps moving.
3. Impact follows when the agent reaches data or systems that were never intended for its current task, because the authorisation layer cannot re-evaluate each action fast enough. The same control gap also weakens forensics and compliance evidence.
4. The attacker objective is to convert a trusted agent runtime into broad, persistent operational reach that can touch sensitive data and infrastructure without repeated review.

Breaches seen in the wild

• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

Continuous authorization is becoming the missing control plane for AI agents. Human IAM can still authenticate people and govern durable sessions, but it does not describe workloads that take thousands of action-level decisions. Once the authorisation problem moves into runtime, policy must evaluate each action against current context rather than inherited trust. Practitioners should treat continuous authorization as an operating model, not an add-on feature.

Identity assertion, delegation traceability, and autonomy metadata are now core governance inputs. The article makes the right architectural point that a policy engine cannot compensate for an identity model that cannot distinguish a workload from the human who requested it. Delegation chains matter because they preserve accountability across nested agent behaviour. Autonomy metadata matters because approval-before-every-action and fully autonomous execution are different control problems.

Role binding is the wrong abstraction for agentic work. Roles assume a stable job function, but agent scope changes with the prompt, the task, and the downstream tools it discovers. That creates a governance mismatch that role design alone cannot close. The practical implication is that authorization for AI agents needs task-scoped decisioning, not a recycled employee access model.

Enforcement must track where agent decisions actually land, not where they originate. The strongest part of the architecture is its recognition that application, infrastructure, data, and AI tool calls are all separate enforcement surfaces. If one of those domains is left outside the decision path, the policy engine becomes advisory rather than authoritative. Security teams should view domain coverage as a control integrity question, not a tooling preference.

Decision logs are now a governance artefact, not an afterthought. Continuous authorization only becomes defensible when the organisation can reconstruct who asked, what the engine decided, and why. That is especially important when regulators, boards, and incident responders all need the same evidence chain. The practitioner takeaway is simple: if the decision cannot be explained, it cannot be governed.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Decision-centric authorisation is now the right model for AI agents. The old habit of trusting a login event no longer matches how agentic workloads behave, because the control problem sits at each action rather than at the start of a session. Organisations that keep treating agent access as static will keep discovering that their policies describe intent, not execution.

Agent scope is the new governance boundary. A single AI system can shift from harmless retrieval to sensitive write access inside one workflow, so security teams need controls that follow the task rather than the user record. Without that shift, access review and role design remain one step removed from actual runtime risk.

70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey cited by 2026 Infrastructure Identity Survey. That gap matters because authorisation assumptions are already being stretched beyond the boundaries they were built for, and the result is governance debt that accumulates faster than review cycles can close it.

For practitioners

• Inventory non-human identities across production Build a current count of agents, service accounts, API keys, and machine credentials before trying to retrofit continuous authorization. The architecture depends on knowing which workloads are already asking for access and where they run.
• Add identity assertion for each new agent workload Issue cryptographically verifiable workload identity and record who the agent is acting for before policy evaluation begins. Avoid attaching new agents to shared service accounts or borrowed long-lived credentials.
• Require per-action policy evaluation for agent requests Treat allow, deny, or escalate as a decision made on every discrete action, not at login time. Include resource sensitivity, action type, delegation chain, and autonomy metadata in the decision inputs.
• Expand enforcement beyond the API gateway Check applications, infrastructure, data stores, and AI tool calls as separate enforcement domains that must all return the same policy result. A gateway-only model leaves direct data paths and internal agent calls ungoverned.
• Centralise decision logs for audit and forensics Store who asked, what was requested, which policy fired, and why the engine allowed or denied the action. Use the same record set for compliance reporting, behavioural baselining, and incident reconstruction.

Key takeaways

• AI agents expose a gap between identity at login and authority at action time, which makes human-session IAM an incomplete control model for runtime decisioning.
• The article’s architecture combines workload identity, context, enforcement, and audit because no single layer can explain or constrain agent behaviour on its own.
• For practitioners, the practical shift is to govern the agent’s task path and decision logs, not just the account or role attached to the workload.

Key terms

• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Autonomy Metadata: Autonomy metadata describes how independently an AI agent is permitted to make decisions during execution. It records whether human approval is required, what actions can be taken without review, and how much discretion the agent has when selecting tools or follow-on steps.
• Decision-centric authorization: Decision-centric authorization is a governance model that evaluates each action before it happens, using identity, context, and policy together. For autonomous or machine-speed actors, it is more reliable than static access grants because it tracks behaviour as it unfolds.

Deepen your knowledge

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