Runtime authorization for AI agents: the identity gap in spending

At a glance

What this is: This analysis examines why AI agents can spend, provision, and delegate beyond intended limits when runtime authorization is missing.

Why it matters: It matters because IAM, PAM, and identity governance teams now have to govern actions, not just access, across agentic, NHI, and human workflows.

By the numbers:

• 65% of enterprises running AI agents experienced at least one agent-related incident in the past twelve months.
• 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024.
• 95% had encountered unexpected cloud storage charges that disrupt budgets, slow innovation, or limit flexibility.

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

Context

AI agent spending risk is a runtime identity problem, not just an automation problem. Once an agent can spend money, provision infrastructure, or delegate work, the question changes from what it is allowed to access to what it is allowed to do at a specific moment with a specific credential.

The current control pattern still assumes ownership is assigned at deployment and remains stable enough to govern later actions. That assumption breaks when the credential is used minutes, hours, or months after registration, because the human owner on record is not bound to the transaction itself.

Key questions

Q: How should security teams govern AI agents that can spend money or provision infrastructure?

A: They should treat the agent as a runtime actor, not just a registered identity. The control point belongs between the agent and the tool, where policy can inspect the prompt, target system, and action type before approving execution. Static credentials alone are not enough because they cannot distinguish a permitted read from an unintended transaction.

Q: Why do AI agents create more risk than traditional automation for spending controls?

A: Traditional automation follows predetermined rules, while AI agents can decide when to act and what tool path to take at runtime. That makes their transactions less predictable and more likely to convert a small error into a real purchase, scale event, or production change before a human can intercept it.

Q: What breaks when agent ownership is only recorded at deployment time?

A: The link between the human owner and the actual transaction breaks. A static registry entry can show who created the agent, but it does not prove who approved a later purchase, provisioning event, or delegated action. Without runtime binding, accountability exists on paper but not at execution.

Q: Who is accountable when an AI agent makes an unauthorised transaction?

A: Accountability should rest with the governance chain that allowed a standing credential to act without runtime approval. The human approver, the policy owner, and the system owner all have roles, but the key test is whether the specific action was cryptographically bound to a verified approver at the moment of execution.

Technical breakdown

Why deployment-time ownership breaks at runtime

Most enterprise agent setups rely on credentials issued at deployment, such as API keys, service account tokens, or OAuth credentials stored in secrets managers. Those credentials prove that an agent is authenticated, but they do not establish who authorised a specific action at execution time. When the agent can choose when to act and what transaction to trigger, static ownership records become an audit artefact rather than a control. The result is a gap between registration and execution that traditional IAM does not close.

Practical implication: Treat agent registration as inventory, not authorization, and add an execution-time control layer before any write or spend action proceeds.

How runtime authorization changes agentic AI governance

Runtime authorization inserts a policy decision point between the agent and the target tool. The policy evaluates the prompt, the data source, and the action type before execution continues. Read-only access may pass automatically, while money movement, production changes, and sensitive data access trigger human approval or step-up authentication. In practice, this turns the agent from a self-contained executor into a subject whose action is validated against live context. That is a different governance model from standard access control.

Practical implication: Route all consequential agent actions through a policy engine that can block, step up, or bind the transaction to human approval.

Why approval thresholds need cryptographically bound identity

A threshold is only enforceable when the approving human is cryptographically attached to the action the agent will take. Without that binding, an agent can repeatedly fragment work into smaller requests, change code paths, or reuse credentials outside the intended context. A verifiable credential issued for one approved action is stronger than a standing permission because it narrows scope, expires quickly, and preserves accountability at the moment of execution. This is where runtime identity becomes the control substrate, not a feature around the edge.

Practical implication: Use time-bound, action-bound credentials for agent transactions and revoke them automatically when the approval context ends.

Threat narrative

Attacker objective: The objective is to make valid agent-driven transactions execute without a live human decision attached to each consequential action.

1. Entry occurs when the agent receives a valid deployment-time credential such as an API key, service account token, or OAuth secret.
2. Escalation happens when the agent uses that credential to take a broader action than a human would have approved in context, such as overspending or provisioning at scale.
3. Impact appears as direct financial loss, uncontrolled infrastructure growth, or repeated transactions that were never re-authorised.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime identity is the missing control plane for agentic spending. The vendor correctly frames the problem as execution-time authority rather than registration-time ownership. That matters because agentic systems are not simply automated workflows with a new label. They can choose actions, timing, and tool paths in ways that make static ownership records insufficient for governance. The implication is that action authorization must sit alongside identity issuance, not after it.

Deployment-time governance assumes a stable authorizer, and that assumption fails for agents. Traditional access review logic was designed for actors whose permissions persist long enough to be observed, certified, and remediated. When an agent can spend, provision, or delegate within a live session, the governance object is the transaction, not the standing entitlement. The implication is that identity governance must shift from who holds access to who approved this action right now.

Context-aware authorization is becoming the boundary between acceptable autonomy and uncontrolled spend. The article shows that prompt, source, and action context can be used to distinguish harmless reads from consequential writes or purchases. That is a strong fit for OWASP-AGENTIC and NIST AI RMF thinking, but only if the policy layer is actually enforced at runtime. The implication is that agent autonomy must be bounded by transaction-aware controls, not trust in the model's judgment.

Ghost Agent risk is an orphaned credential problem, not just an inventory problem. Once the original human owner leaves or changes role, a standing credential can keep executing if runtime binding is absent. That is a lifecycle failure with direct financial consequences, and it sits at the intersection of NHI governance and autonomous action control. The implication is that offboarding logic must reach the action layer, not stop at registration records.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• For a broader control model, review 52 NHI Breaches Analysis for the recurring lifecycle and privilege failure patterns that runtime authorization needs to close.

What this signals

Runtime governance gap: agentic systems now need controls that evaluate actions at execution time, not just entitlements at issuance. In practice, that means IAM teams should expect spending, provisioning, and delegation to be governed as transactions, with policy enforcement tied to the moment the agent acts.

The scale signal is already visible. With 65% of enterprises running AI agents reporting at least one incident and 33% of enterprise software expected to include agentic AI by 2028, the number of transactions that need runtime review will rise faster than current approval workflows can absorb.

For practitioners, the governance boundary is shifting from registration to runtime binding. If the human approver is not attached to the specific transaction, the control is advisory rather than enforceable, which is why action authorization must become part of the identity architecture.

For practitioners

• Separate registration from authorization Keep agent inventory, ownership records, and runtime action approval as distinct controls. Registration should tell you the agent exists, while runtime authorization decides whether a spend, write, or delegation action can proceed.
• Interpose a policy engine before every consequential tool call Place an enforcement point in front of procurement, infrastructure, and SaaS management tools so the agent cannot execute a write or purchase action without policy evaluation. Use the policy to classify prompt, target system, and transaction type.
• Bind approvals to verifiable, time-bound credentials Issue credentials only after human approval for the specific action, then scope and expire them so they cannot be reused for a different transaction. This reduces the chance that an agent turns one approval into repeated spend.
• Instrument denied actions as governance telemetry Treat denied transactions as evidence of policy quality, not just failed user experience. Review the patterns to find noisy triggers, over-broad thresholds, and agent logic that needs retraining or tighter limits.

Key takeaways

• AI agents create a governance problem when valid credentials are allowed to trigger consequential actions without runtime approval.
• The evidence points to broad exposure, with incidents, unexpected charges, and excess privilege all showing how fast agentic errors become real losses.
• The control that changes the outcome is runtime authorization with cryptographically bound human approval, not another static registry entry.

Key terms

• Runtime Authorization: Runtime authorization is the decision to allow or block a specific action at the moment it is about to happen. For AI agents and other non-human identities, it matters because authentication alone cannot tell you whether a spend, write, or delegation step should proceed right now.
• Verifiable Credential: A verifiable credential is a cryptographically signed assertion that can prove who approved an action and under what scope. In agentic identity governance, it is used to bind a human approver to a specific transaction so the credential can be checked, limited, and expired with precision.
• Ghost Agent: A Ghost Agent is an agent that keeps operating after the original owner has left, changed role, or lost oversight. The risk is not the agent's existence, but the persistence of credentials and permissions that were never tied to runtime accountability or properly revoked.
• Action Authorization: Action authorization is the practice of governing what a subject may do at a specific execution point, not just what it can access. For agents, it closes the gap between holding a valid credential and being allowed to create a purchase, change infrastructure, or hand off authority.

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 maturity, it is worth exploring.

This post draws on content published by 1Kosmos: runtime authorization for AI agents and the identity gap in spending. Read the original.