According to the Kiteworks 2026 Data Security and Compliance Risk Forecast, 60% of organizations cannot terminate a misbehaving AI agent quickly, and 63% are struggling to enforce purpose limitations on what agents are authorized to do.
Both controls sit at the execution layer, and both are exactly what runtime authorization is built to close.
Runtime authorization for AI agents is buildable today. The standards are in place (W3C Verifiable Credentials, CIBA), the deployment model is well-defined (MCP gateway), and the architecture fits alongside the registration tools enterprises already run.
This piece is for security architects and engineering leads evaluating what it takes to put runtime authorization in front of agents that can spend money, change infrastructure, or access sensitive data. It covers where the authorization layer sits, how credentials flow, how policy gets configured, and how to phase the rollout.
Where the authorization layer sits
The authorization layer sits between the agent and the tool. It deploys as an additional MCP server in front of your existing MCP infrastructure, intercepting every tool call before it reaches the underlying API or service.
Placement matters here. Agents built across LangChain, Relevance AI, Copilot Studio, and custom frameworks all converge on MCP as the tool access layer. By intercepting at the MCP boundary, the authorization layer enforces policy consistently regardless of which framework produced the agent or how its credentials were configured at deployment.
The layer integrates with three things:
The identity provider (Microsoft Entra, Okta, Auth0) for verifying the human authorizer and detecting offboarding events
The MCP infrastructure for intercepting tool calls
The mobile wallet that delivers approval requests to the human authorizer over CIBA
The authorization layer does not replace your registration layer. Microsoft Entra Agent ID and ServiceNow track agents at creation. The authorization layer governs every action the agent takes after that.
The verifiable credential flow
A Verifiable Credential is the artifact that authorizes a specific agent action. It carries five fields:
Issuer: the human authorizer who signed it
Binding: cryptographic link to the specific agent
Validity: time window, typically minutes to hours
Scope: the permitted action (e.g., "place purchase order," "read email")
Context: environment, target resource, risk signals
The credential is signed using public-key cryptography. Any tool holding the issuer's public key can verify the signature without calling back to the authorization service.
CIBA flow in sequence
Client Initiated Backchannel Authentication (CIBA) is the protocol that pushes the approval request to the human at runtime. CIBA decouples the device making the request (the agent) from the device that authenticates (the human's phone), which is exactly the topology runtime authorization needs. Here is the sequence for a procurement agent attempting a $1,200 order:
Interception. The Policy Engine intercepts the MCP call before it reaches the procurement API.
Policy evaluation. Policy says orders over $400 require human approval. The engine halts execution.
Push notification. A request is pushed to the owner's mobile wallet over CIBA. The notification includes agent identity, vendor, amount, and validity window.
Biometric approval. The owner reviews the request and approves with biometric verification.
Credential issuance. The authorization service issues a VC scoped specifically to this order, bound to this agent, valid for the approved window.
Execution. The agent presents the credential to the procurement API. The API verifies signature, scope, and validity, then places the order.
Total elapsed time is seconds. The agent does not wait long, and the human user approves from their phone without logging into a separate console.
Policy configuration
Policies evaluate three dimensions on every call: the prompt, the data source, and the action.
Dimension | What it asks | Example signal |
|---|---|---|
Prompt | What is the agent being asked to do? | Sensitive query types flag for step-up |
Data source | Which tool or system is targeted? | Financial, HR, and infra carry higher risk |
Action | What will the agent change? | Reads pass, writes route to approval |
A procurement policy might allow orders under $400 to auto-approve, while anything at $400 or above requires step-up authentication and sends a push notification to the owner for approval.
Policies can also adjust based on agent track record, time of day, network location, and external risk signals. An agent that normally provisions two servers at a time triggers approval if it suddenly attempts fifty.
Enforcement happens at the network layer. No changes to the underlying tool, ServiceNow workflow, or orchestration platform are required.
Lifecycle management
Credentials are issued, renewed, and revoked through the same authorization service, keeping the full lifecycle under a single control plane.
Issuance happens at the moment an action is authorized. Renewal is policy-driven: some actions allow auto-renewal within a window (a customer service agent reading records under the same open ticket, for example), while others require fresh approval each time (any new financial transaction). Revocation can occur before expiration when a policy changes, suspicious behavior surfaces, or the human authorizer is offboarded.
That last case is handled automatically. When an account is deactivated in the identity provider, the authorization service queries every agent owned by that human and revokes their credentials immediately. Any subsequent action attempt is denied. This closes the Ghost Agent gap, where orphaned credentials continue executing after their original owner has left, without requiring manual cleanup.
Every authorization decision is logged with the agent identity, action attempted, target resource, timestamp, policy evaluated, decision, and the approving human. Logs are immutable and exportable for compliance audits.
Deployment sequence
A practical rollout looks like this:
Inventory agents. Document what agents exist, what tools they access, and which credentials they hold today. Most environments have more agents than the security team knows about. One Fortune 100 environment recently audited 700 agents discovered, 24 MCP servers in production, and fewer than 10 governed workflows.
Stand up the MCP gateway. Deploy the gateway in front of existing MCP infrastructure. No agent code changes required.
Connect identity sources. Integrate with Microsoft Entra, Okta, or Auth0 for human identity verification and offboarding signals.
Define policies for the highest-risk agents first. Procurement agents that can spend money. Infrastructure agents that can modify production. Customer service agents that can access regulated data.
Enable CIBA on owner devices. Provision the 1Kosmos Wallet to agent owners. Test push notification flow with a small group.
Pilot with three to five agents. Monitor approvals, denials, and policy hits. Adjust thresholds based on operational feedback.
Enable the kill switch. Confirm that deactivating a test owner account in the identity provider revokes the agent's credentials within seconds.
Scale. Move remaining high-risk agents under the gateway, then expand coverage to lower-risk agents in subsequent phases.
The gating factor is policy definition, not infrastructure deployment.
How 1Kosmos handles runtime authorization
The 1Kosmos Policy Engine deploys as an MCP gateway in front of your existing tool infrastructure, intercepting every agent action before it executes and validating a time-bound, scope-bound credential before anything reaches its target.
Intercepts at the MCP layer: Every agent tool call passes through the Policy Engine before reaching the underlying API or service. No agent code changes required.
Validates credentials on every execution: The engine checks issuer identity, scope, and validity window on each call. An expired or out-of-scope credential blocks execution immediately.
Pushes biometric approval to a verified human: When an action crosses a policy threshold, an authorization request goes to the owner's 1Kosmos Wallet over CIBA. The human approves or denies with biometric verification in seconds.
Revokes access the moment an employee is offboarded: When an account is deactivated in the identity provider, every credential tied to that human is cryptographically nulled. Agents they owned stop executing without any manual intervention.
Where 1Kosmos sits relative to your control plane
Microsoft Entra Agent ID and ServiceNow solve a real problem: they track which agents exist, who owns them, and what they were provisioned to do.
That registry matters, but the gap is that ownership defined at registration has no operational link to what the agent does three months later. An agent that was assigned to an employee at creation is still running under that credential after the employee leaves, after the scope has shifted, and after the original context that justified provisioning no longer applies.
Registration answers the question of who created the agent. Runtime authorization answers the question of whether this specific action, at this specific moment, has a verified human behind it. Those are different questions, and only one of them stops an unauthorized transaction before it completes.
1Kosmos operates at the execution layer, which is precisely where Entra stops. Every call the agent makes passes through the Policy Engine and every credential is validated against scope, issuer, and validity window before the tool executes. The two layers are complementary: registration tracks the agent across its lifecycle, runtime authorization governs every action it takes.
Conclusion
Runtime authorization works because every consequential action is bound to a verified human at the moment of execution. The credential cannot exist without an active human binding, cannot be reused outside its scope, and cannot survive past its validity window.
For environments running agents at scale, that binding is what converts spending controls and access policies from advisory to enforceable. Microsoft Entra Agent ID and ServiceNow handle the registration side. The runtime side is where unauthorized spend, ghost agents, and untraceable actions actually happen, and where this layer earns its keep. The infrastructure is available now. The next decision is which agents go under the gateway first.
Learn more about how 1Kosmos handles runtime authorization for AI agents and contact us if you have any questions, or want to see it in action.
—
FAQs
What is AI agent runtime authorization?
Runtime authorization evaluates every AI agent action at the moment of execution. An MCP gateway intercepts each tool call, checks it against policy, and either approves it automatically, routes it to a verified human, or blocks it entirely. Access requires a time-bound, scope-bound credential issued for that specific action, not a standing key provisioned at deployment.
How does runtime authorization differ from agent registration?
Agent registration tools like Microsoft Entra Agent ID track ownership at creation. Runtime authorization operates at execution, validating credentials on every tool call. Registration records who created the agent; runtime authorization verifies whether a specific action, at this moment, has an authorized human behind it. Those are different controls solving different problems.
What are verifiable credentials in AI agent security?
A verifiable credential is a cryptographically signed token that authorizes a specific agent action within a defined scope and time window. It expires quickly, cannot be reused outside its approved scope, and is bound to the issuing human's identity. Unlike a static API key, a verifiable credential is useless to an attacker once its validity window closes.
How does the CIBA protocol enable human approval for AI agents?
CIBA (Client Initiated Backchannel Authentication) decouples the device making the request from the device that authenticates. When an agent action crosses a policy threshold, a push notification goes to the owner's mobile wallet. The owner approves with biometric verification, and a scoped credential is issued to the agent in seconds, with no separate console login required.
What is a ghost agent and how does runtime authorization stop it?
A ghost agent is an AI agent that keeps executing after its human owner leaves the organization, operating on credentials that were provisioned at deployment and never revoked. Runtime authorization eliminates this by binding every credential to an active human identity. When the owner is offboarded, all credentials tied to their agents are cryptographically revoked immediately.
About the author
Huzefa Olia
Co-Founder & Chief Operating Officer
Huzefa is the COO and a co-founder of 1Kosmos with 18+ years in identity and access management and cybersecurity, focused on scaling operations, go-to-market strategy, and enterprise partnerships across global markets.
