AI & Identity

Preventing AI Agents from Autonomous Spending

Huzefa Olia

Co-Founder & Chief Operating Officer

A close-up of a glowing blue digital circuit sphere wrapped in luminous data streams, representing AI agents executing autonomous transactions across connected infrastructure.

Sixty-five percent of enterprises running AI agents experienced at least one agent-related incident in the past twelve months, and more than a third of those incidents caused direct financial loss, according to Cloud Security Alliance's April 2026 report.

The agents are performing as designed. The gap sits in the governance layer around them. Specifically: at the moment of execution, you don't know who's behind the credential the agent is using when it spends.

The identity gap behind the spending problem

AI is evolving faster than the controls built to govern it. Chatbots were passive (summarize this PDF) and background processes were invisible automation (run this maintenance script).

But agentic models are autonomous and transactional (spin up 50 servers, order 500 laptops). As these agents gain the ability to spend money and change infrastructure, security has to evolve from access control to action authorization.

Most agents authenticate using credentials configured at deployment:

  • API keys

  • Service account tokens

  • OAuth credentials stored in environment variables or secrets managers

These credentials grant blanket authority; once an agent holds a valid key, the tool must execute, but it has no concept of which human is responsible for the action it's about to take.

Current control planes solve registration, not runtime

Microsoft Entra Agent ID and ServiceNow assign ownership at agent creation and track it as a static registry entry. Three months later, when the agent orders laptops or provisions servers, the original human owner is on record but has no operational link to that specific action. Ownership is defined at infancy, not at runtime execution.

Probabilistic reasoning introduces failure modes that deterministic automation does not have

From misinterpreted metrics and hallucinated requirements to context errors, when the agent holds credentials with broad scope and no runtime accountability, each of these translates directly into executed transactions.

Here's what that looks like in production:

How overspending happens

Consider a procurement agent deployed to manage hardware reordering across regional offices. It tracks inventory signals, calculates demand, and places orders against approved vendor catalogs.

The logic works, until an inventory signal misread, a stale vendor catalog response, or a duplicate trigger from two upstream systems causes the agent to place an order that no one would have approved if a human had seen it first.

The agent acts on its instructions and the credential validates, so the order ships.

Now assume this pattern repeats across agent categories:

  • License management agents purchase seats when they detect capacity constraints

  • A bug in utilization tracking, a timezone overlap between regional reporting systems, or a misread of what "active" means can drive automated purchasing of hundreds of unused seats before anyone reviews the decision

  • Infrastructure agents auto-scale compute resources in response to load signals that may or may not reflect legitimate demand

These aren't isolated agent problems. They're agent-accelerated versions of waste patterns already documented across enterprise IT.

A 2025 Backblaze and Dimensional Research survey of 403 IT leaders managing more than 250TB of cloud data found that 95% had encountered unexpected cloud storage charges that disrupt budgets, slow innovation, or limit flexibility.

Agents with autonomous spending authority do not create the underlying error rate; they accelerate it by removing the human checkpoints that used to intercept misreads before they became transactions. Gartner predicts 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024, showing how aggregate exposure scales with adoption.

Enforcement architecture: approval gates and scoped credentials

Preventing AI agent overspending requires a shift from identity-based access to context-aware authorization at runtime.

Every agent action gets evaluated against three factors before execution proceeds:

  1. The prompt. What is the agent being asked to do? Sensitive prompts flag for step-up authentication.

  2. The data source. Which tool or system is the agent reaching? Financial systems, HR data, and infrastructure provisioning carry higher risk.

  3. The action. What will the agent change? Read-only queries pass through. Write operations, money movement, and infrastructure changes route to human approval.

How approval works in practice

An engineering agent is asked to wake up infrastructure ahead of a scheduled load test. The unguarded version of this scenario is short: the agent calls the provisioning tool, the hardcoded API key validates, 50 servers come online in seconds, and no audit trail records which human was accountable for the spend.

The governed version takes three steps and adds seconds, not minutes.

  1. Interception. The Policy Engine intercepts the MCP call before it reaches the provisioning tool. No Verifiable Credential is present. Execution is blocked. The agent triggers an authentication request.

  2. Human authorization. The agent halts and pushes an authorization request to the owner's mobile wallet via the CIBA protocol (Client Initiated Backchannel Authentication). The human reviews the request, the agent identity, the scope, and the validity window, then approves or denies with biometric verification.

  3. Binding and execution. A Verifiable Credential is issued, cryptographically bound to the approving human, scoped to the approved action, and time-bound to a defined validity window. The agent presents the credential. The tool verifies issuer, scope, and validity. The infrastructure provisions. The action is logged with the human's biometric signature attached.

The scoping is what matters. The credential cannot be reused for a different operation. It expires inside its validity window. Every action is traceable to a verified human who explicitly approved that specific transaction at that specific moment.

Implementation across agent types

The walkthrough above shows one agent action. The same authorization layer governs multiple agent types simultaneously, each operating under thresholds tuned to its action profile, with no code changes required to the underlying agents.

Four common categories of agent action sit inside the governance scope:

Action category

What's at stake

When approval triggers

Infrastructure provisioning

Compute, storage, networking spend; production stability

Production environment changes, bulk provisioning, dollar threshold breaches

Procurement authorization

Direct financial transactions; vendor relationships

Transaction value thresholds, first-time vendors, budget code validation

Chatbot data access

Sensitive data exposure; compliance scope

Read access to regulated data sources; cross-tenant queries

Agent-to-agent delegation

Privilege chains; accountability

Any handoff that escalates scope or extends the action chain

Configurations are customer-defined. The same policy engine evaluates each call regardless of which category it falls into.

Measuring impact

The scale of exposure is external to any individual deployment:

  • 35% of AI agent incidents in the CSA survey caused direct financial loss

  • 95% of IT leaders have encountered unexpected cloud storage charges that disrupt budgets (Backblaze 2025)

  • A 1Kosmos audit of a Fortune 100 environment discovered 700 agents, 24 MCP servers in production, and fewer than 10 governed workflows

An autonomous agent operating without runtime authorization inherits those baseline error rates and accelerates them by removing the human review that traditionally slowed the worst cases. Return on a runtime authorization layer compounds against those baseline rates. Any reduction in the percentage of erroneous transactions that complete without human review flows directly to the bottom line.

What runtime authorization delivers

Runtime authorization value shows up in four places that can be measured inside any deployment:

  1. Cryptographically signed approval records for audit, with the verified human attached to every consequential action

  2. Real-time visibility into spending patterns

  3. Reduced forensic overhead when charges appear unexpectedly

  4. Agent performance data from denied authorizations that surfaces logic flaws for retraining

Approval overhead is modest. Typical flows complete in seconds, and in most deployment profiles only a fraction of agent actions hit the approval threshold at all.

Why spending controls need runtime identity to hold up

Threshold-based approval gates are necessary, but they're the visible part of a control system, not the load-bearing part.

What makes them work is the verified human behind every action that crosses a threshold. Without that, an approval gate is just a static rule that an agent with broad credentials can satisfy by hitting a different code path or burning through a smaller transaction repeatedly.

Runtime identity is the substrate

It binds every agent action to a specific human authorizer at the moment of execution, expires the credential as soon as the action is complete, and revokes everything cryptographically the moment the human is offboarded. The Ghost Agent problem (orphaned credentials still executing after the original owner has left) disappears, because the credential can’t exist without an active human binding.

This is where 1Kosmos operates

Microsoft Entra Agent ID and ServiceNow handle agent registration. 1Kosmos handles runtime authorization through an MCP gateway that sits in front of existing tool infrastructure, evaluates every agent action against policy, and issues Verifiable Credentials only after a human has approved the specific operation.

The two layers are complementary:

  1. Registration tracks the agent across its lifecycle

  2. Runtime authorization governs every action it takes.

Read: Implementing runtime auth for AI agents

For enterprises, the practical effect is that spending controls become enforceable instead of advisory. The policies you define actually hold, because no agent can act without a credential that traces back to a human who said yes to that specific action at that specific time.

Closing thoughts

The organizations we work with want to scale AI agent deployments without scaling financial risk alongside them. Runtime identity is how those two objectives coexist.

Agents keep the decision-making latitude that made them valuable, and the business keeps a verified human attached to every consequential action. The control layer is what makes the autonomy safe to use at scale, and identity at runtime is what makes the control layer real.

Ready to bring runtime controls to your agent deployments?

Learn more about how 1Kosmos handles runtime authorization, or book some time with one of our AI governance specialists if autonomous agent spending is on your radar.

FAQ

Can AI agents make purchases without human approval?

Yes. Any AI agent connected to a procurement system, cloud provider API, or SaaS management platform can initiate a transaction on its own once it holds a valid credential. The agent decides when its internal logic warrants action, and the credential validates the request without checking whether a human authorized that specific spend. Preventing this requires a control layer that intercepts the agent's request before it executes and applies approval policies based on amount, context, and risk.

How is runtime authorization different from traditional IAM?

Traditional identity and access management answers two questions: who is the agent, and what is it permitted to access. Runtime authorization adds a third question that traditional IAM does not address: should this specific action be allowed right now, given the amount, context, and current business conditions. The result is a scoped, time-bound credential issued only after the request has been evaluated against live policy, with human approval routed in for any action above defined risk thresholds.

What types of AI agents need spending controls?

Any agent with a path to financial impact. Procurement agents that reorder supplies and equipment fall into this category, as do cloud infrastructure agents that auto-scale compute capacity and SaaS license agents that purchase seats based on utilization signals. The shared characteristic is access to a system that can move money or commit budget. Once an agent is wired into that kind of system, threshold-based approval policies become the minimum control surface required to keep autonomous decisions from turning into uncontrolled spend.

Why aren't API keys enough to prevent AI agent overspending?

API keys and OAuth tokens were designed to answer one question: is the caller permitted to make this kind of request. They cannot evaluate the amount of the transaction, the production sensitivity of the environment, or whether the business actually wants the agent to execute right now. A key authorized to provision compute resources will validate a request for one instance and a request for hundreds with equal indifference. Preventing overspending requires a policy layer that runs between the agent and the tool, evaluating each call on its specific merits before any credential is issued.

How long do AI agent approval workflows take?

Seconds, typically. A well-designed flow intercepts the agent's request, evaluates it against policy, routes a notification to the designated approver, captures the human's biometric approval, and issues a scoped credential that the agent uses to complete the action. Mobile-first delivery keeps the approver out of any specific workspace or VPN, which is what holds the total time low. Only a fraction of agent actions hit the approval threshold in the first place, so the overhead falls on a small slice of total agent activity.

Sources

Cloud Security Alliance. Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises. Survey commissioned by Token Security, conducted online by CSA in January 2026, based on 418 responses from IT and security professionals. Published April 21, 2026. https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments

Backblaze and Dimensional Research. The Hidden Cost of Cloud Storage: What 400+ IT Leaders Wish They Knew Sooner. 2025 Cloud Storage Survey of 403 IT leaders managing 250TB or more in the cloud, fielded May and June 2025. Published October 30, 2025. https://www.backblaze.com/blog/the-hidden-cost-of-cloud-storage-what-400-it-leaders-wish-they-knew-sooner/

Gartner. How Intelligent Agents in AI Can Work Alone. Forecast that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. https://www.gartner.com/en/articles/intelligent-agent-in-ai

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.

The latest in identity security.

Enter our orbit.

The latest in identity security.

Enter our orbit.

The latest in identity security.

Enter our orbit.

Transform how you verify and authenticate

Secure onboarding, eliminate passwords, and stop fraud on one platform. Schedule a demo and see it in action.

Transform how you verify and authenticate

Secure onboarding, eliminate passwords, and stop fraud on one platform. Schedule a demo and see it in action.

Transform how you verify and authenticate

Secure onboarding, eliminate passwords, and stop fraud on one platform. Schedule a demo and see it in action.