Runtime authorization for AI agents: closing execution-layer control gaps

At a glance

What this is: This is an analysis of runtime authorization for AI agents, showing how execution-layer policy, verifiable credentials, and human approval can constrain agent actions after registration.

Why it matters: It matters because IAM, PAM, and identity governance teams need controls that govern what agents can do at runtime, not just who created them or what they were intended to do.

By the numbers:

• 60% of organizations cannot terminate a misbehaving AI agent, and 63% are struggling to enforce purpose limitations on what agents are authorized to do.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read 1Kosmos's analysis of runtime authorization for AI agents

Context

AI agent runtime authorization is the control layer that decides whether an action should proceed at the moment it is attempted. In this model, the agent may request access, but a separate policy decision and human accountability layer determine whether the tool call is allowed.

The governance gap is not registration. Many enterprises can record that an agent exists, but that does not control what it does after deployment, when scope drifts, credentials outlive their original purpose, or the owner changes.

This is increasingly an IAM and PAM problem as much as an AI problem, because the same control assumptions that govern service accounts and privileged workflows are now being tested by agents that can take independent actions inside business processes.

Key questions

Q: How should security teams govern AI agents that can take high-risk actions at runtime?

A: Security teams should put policy enforcement in front of agent tool calls, not behind them. The right model is action-time evaluation with scope, context, and human accountability attached to each request. Registration remains useful for inventory, but it cannot replace runtime governance when the agent can spend money, change infrastructure, or reach sensitive systems.

Q: Why do static permissions fail for AI agents and delegated workflows?

A: Static permissions fail because agent intent and context can change after the credential is issued. A permission that looked acceptable at deployment can become unsafe in the next action sequence if the agent switches tools, targets a different system, or operates under a new risk condition. Runtime authorization closes that gap by deciding at the moment of execution.

Q: What breaks when human approval is not tied to a specific agent action?

A: When approval is generic, it becomes impossible to prove what the human actually authorized. That creates weak accountability, reusable consent, and poor audit evidence. A secure model binds the approval to one action, one scope, and one validity window so the human decision is cryptographically traceable and cannot drift into standing access.

Q: How do organisations know whether agent governance is actually working?

A: Look for blocked out-of-scope calls, time-bound credentials, immutable decision logs, and automatic revocation when the accountable owner changes. If you can only prove that an agent was registered, you do not have governance. If you can prove every action was evaluated and attributed in real time, the control is working.

Technical breakdown

Where runtime authorization sits in the MCP tool path

Runtime authorization is placed between the agent and the tool, usually as an MCP gateway that intercepts every tool call before it reaches the underlying API. That placement matters because it makes policy enforcement framework-agnostic: agents built in different orchestration stacks can still be governed by the same decision point. The key distinction is between registration, which records the agent, and execution control, which governs each action. This is the practical boundary where policy can inspect the requested action, the target data source, and contextual risk before the call is released.

Practical implication: enforce policy at the MCP boundary so runtime decisions apply consistently across every agent framework.

How verifiable credentials and CIBA bind human approval to agent actions

A verifiable credential is the signed authorization artifact for one specific agent action. It can encode issuer, binding to the agent, validity window, scope, and context, which allows downstream tools to verify the decision without repeatedly consulting the policy service. CIBA adds the human approval loop by pushing a backchannel request to the authorizer's device at runtime, separating the agent request from the human authentication step. Together, these controls make a human approval cryptographically specific to a single action, not a generic standing consent.

Practical implication: scope approvals to a single action window so human sign-off cannot be reused outside the intended task.

Why lifecycle revocation and kill switches matter for agent governance

Runtime authorization is only durable if issued credentials can also be renewed and revoked through the same control path. That allows policy changes, suspicious behaviour, and offboarding events to terminate access without manual cleanup. The article's kill switch pattern closes the Ghost Agent problem by revoking every agent credential tied to a deactivated human owner. In governance terms, this is lifecycle enforcement for delegated identity, not just access approval. The control failure being addressed is persistence after accountability has changed.

Practical implication: wire offboarding into credential revocation so agent access ends when the accountable human leaves.

NHI Mgmt Group analysis

Runtime authorization is becoming the missing execution control for AI agent governance. Registration tells you that an agent exists, but it does not stop the agent from spending, changing, or reading outside policy once it is live. That gap is visible wherever enterprises can inventory agents but still cannot constrain action at the point of execution. The practical conclusion is that agent governance now has to include runtime policy enforcement, not just inventory.

Policy at action time matters more than static entitlement at provisioning time. The article shows why pre-authorised access breaks down when agents can operate across changing prompts, data sources, and tools. A permission that looked acceptable when issued can become unsafe within the same operational session if context shifts. Practitioners should treat action-time evaluation as a separate control plane from registration and onboarding.

Human accountability must be tied to each high-risk agent action, not assumed from ownership records. The human who created an agent is not necessarily the person who should approve every future action, and ownership records do not guarantee current accountability. That makes approval provenance and offboarding linkage essential governance evidence. Security teams should rework agent oversight around present-tense accountability, not legacy assignment.

Purpose limitation is no longer a policy statement when agents can execute autonomously inside workflows. The article's most important governance concept is purpose control at runtime, where the system decides whether the current action still fits the approved objective. Without that layer, purpose becomes an intention document rather than an enforceable boundary. The implication is that identity governance must measure whether the requested action still fits context, not whether the agent was once authorised.

Execution-layer governance creates a new identity security baseline for agentic systems. This is where NHI governance, PAM-style approval, and AI agent oversight converge into one control problem. Enterprises that separate those functions will keep finding gaps between registration, privilege, and actual behaviour. The practitioner takeaway is to collapse those silos into one governed decision path.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
• For a broader view of the category risk, read OWASP Agentic Applications Top 10 for the control failures that runtime policy has to absorb.

What this signals

Runtime policy will become the practical control point for AI agent governance. As agents move from pilot use cases to business-critical workflows, teams will need a place where policy, approval, and accountability converge at execution time. The governance question is no longer whether you can register agents, but whether you can still stop them from acting outside purpose once they are live.

Purpose limitation is turning into an operational control, not a policy statement. That shift matters for IAM and PAM teams because the control has to inspect action context, not just identity posture. The most useful programmes will map this to existing lifecycle and privileged-access processes, then extend it to agentic behaviour where the old review cadence is too slow.

With 92% of organisations saying AI agent governance is critical but only 44% having implemented policies, the gap is not awareness, it is control translation. The organisations that solve this first will be the ones that can connect inventory, approval, and revocation into one execution path.

For practitioners

• Define a runtime policy boundary for high-risk agent actions Place policy enforcement at the MCP layer so every tool call is evaluated before it reaches the underlying API or service. Start with agents that can spend money, modify infrastructure, or access regulated data, because those actions create the fastest governance failure if left to registration alone.
• Separate registration from execution governance Keep agent inventory and ownership records, but do not treat them as sufficient controls. Use registration tools to answer who created the agent, then use runtime authorization to answer whether the current action fits policy and whether a verified human is accountable right now.
• Bind approvals to a single action window Issue verifiable credentials with a narrow validity period and explicit scope so approval cannot be reused beyond the approved task. Recheck issuer, scope, and validity on each call so out-of-window or out-of-scope actions are blocked at execution time.
• Connect offboarding to automatic revocation Link identity-provider deactivation to agent credential revocation so the loss of human accountability immediately terminates the delegated access chain. Test that deactivating an owner account revokes every related credential without manual intervention or cleanup.
• Pilot approval thresholds on the riskiest workflows first Begin with a small group of procurement, infrastructure, or customer-service agents and tune thresholds using real approval and denial patterns. Use the pilot to validate policy logic, notification flow, and logging before scaling the control to lower-risk workflows.

Key takeaways

• AI agent governance fails when registration is mistaken for control, because runtime behaviour can diverge from the original approval.
• The strongest evidence in the market is that most organisations already see agent scope violations, yet fewer than half have policies in place.
• The practical fix is to enforce policy at execution time, bind approvals to a single action, and revoke delegated access automatically when accountability changes.

Key terms

• Runtime Authorization: Runtime authorization is the decision to allow or deny a specific action at the moment it is attempted. For AI agents and other non-human identities, it turns policy into an execution-time control instead of a one-time provisioning choice, so scope, context, and accountability can be evaluated before the action completes.
• Verifiable Credential: A verifiable credential is a signed authorization artifact that can be checked by another system without continuously calling back to the issuer. In this context, it carries the approved scope, validity window, and binding to a specific agent, making the approval cryptographically portable and tightly bounded.
• CIBA: Client Initiated Backchannel Authentication, or CIBA, is a protocol that separates the request for approval from the device used for human authentication. That makes it useful when an agent initiates an action but a person must approve it on a separate device in real time.
• Ghost Agent: A Ghost Agent is an agent that keeps operating after its accountable human has been offboarded or its original ownership no longer matches reality. The term describes delegated access that persists after accountability has changed, creating residual execution risk and audit gaps.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: runtime authorization for AI agents and the execution-layer controls behind it. Read the original.