According to the Kiteworks 2026 Data Security and Compliance Risk Forecast, 60% of organizations cannot terminate a misbehaving AI agent, 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.
Runtime authorization defines whether an action should proceed. Authentication determines whether a verified human identity is accountable for it. 1Kosmos operates at the authentication layer, and in production environments, both capabilities are required.
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 human approval channel for routing time-sensitive authorization requests to the responsible owner 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. The human 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 typical procurement policy looks like:
Orders under $400: auto-approve
$400 and above: step-up authentication required, with a push notification sent 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.
Issuance happens when the action is authorized. Renewal is policy-driven; some actions allow auto-renewal inside 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 happen before expiration when a policy changes, suspicious behavior surfaces, or the human authorizer is offboarded.
The kill switch handles the offboarding case automatically. When an account is deactivated in the identity provider, the authorization service queries for every agent owned by that human and revokes their credentials. Any subsequent action attempt is denied. This closes the Ghost Agent problem without manual cleanup.
Every authorization decision is logged with the agent identity, action attempted, target resource, timestamp, policy evaluated, decision, and the human who approved. 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: Configure your approval delivery channel and test the notification flow with a small group before expanding.
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.
Where 1Kosmos fits: Agent authentication
Runtime authorization sets the policy, defining which actions need approval, what thresholds trigger a review, and what scope a credential can cover. Authentication does something different. It confirms that the human behind an approval is who they claim to be, and ties that proof to the exact action being taken. A policy can require sign-off on any order above $400, but authentication is what makes that sign-off real, traceable, and impossible to fake.
1Kosmos works at that authentication layer. It deploys as an MCP gateway in front of your existing tools, adding verified human approval to every policy decision that calls for a person.
What 1Kosmos does:
Intercepts at the MCP layer: Every agent tool call runs through the Policy Engine before it ever reaches the API, with no changes to agent code.
Validates on every call: The engine checks issuer, scope, and validity window each time, so an expired or out-of-scope credential is blocked on the spot.
Routes approvals to a verified human: When an action crosses a threshold, the agent owner gets a push to their 1Kosmos Wallet and approves with a biometric in seconds, leaving a cryptographic record behind every decision.
Revokes at offboarding: Deactivate someone's account, and every credential tied to them is nulled automatically. The agents they owned simply stop running.
Where 1Kosmos sits relative to your control plane
Microsoft Entra Agent ID and ServiceNow track which agents exist, who owns them, and what they were built to do. The catch is that ownership set at registration says nothing about what the agent does months later. An agent assigned to someone on day one keeps running under that credential long after the person has left and its scope has drifted.
It comes down to three questions:
Who created the agent? Registration answers this.
Does this action fit policy right now? Runtime authorization answers this.
Is a verified human accountable for it right now? Only authentication answers this.
A registry covers the first question. 1Kosmos covers the other two, picking up at the execution layer where Entra stops. Registration follows the agent across its lifecycle, and 1Kosmos governs and authenticates each action it takes.
Closing
Runtime authorization works because policy is evaluated at the moment of execution, not assumed from a credential that was provisioned weeks earlier. The credential cannot be reused outside its defined scope and cannot survive past its validity window.
For environments running agents at scale, execution-time policy enforcement is what converts spending controls and access rules 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.
1Kosmos operates at the authentication layer within that runtime framework. Policy determines whether an action should proceed, and the platform determines whether a verified human identity is cryptographically accountable for it.
If your organization is deploying agents that can spend money, change infrastructure, or access sensitive data, runtime authorization is the governance layer and agent authentication is what makes it verifiable.
Learn how 1Kosmos delivers agent authentication or contact us to see it in action.
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.
