Scout: Spend Governance for Credentialed Agents — Enforcing Budgets in Front of the Action

Summary

Two incidents in mid-2026 put the same structural problem on the table from opposite directions. In one, attackers pulled static access keys off an EC2 instance belonging to a three-person agency and burned $14,000 of Claude calls through Amazon Bedrock in a single day, against a normal bill of $10–15 a month (InfoQ; Tobias Schmidt). In the other, no attacker was involved at all: an autonomous agent given AWS credentials and a task decided it needed five m8g.12xlarge instances, load balancers, and Lambda functions to port-scan a hobbyist BGP network, repeatedly redeployed the same CloudFormation template, and ran up $6,531.30 in under a day on a workload the community priced at about $5 a month on a VPS (Lan Tian; InfoQ). Different threat models, identical failure: the control that was supposed to catch it was the bill, and the bill arrives late. That lag is documented, not incidental — AWS’s own guidance states that “AWS Budgets information is updated up to three times a day” with updates “typically occur 8–12 hours after the previous update” (AWS Cost Management docs). Any ceiling denominated in dollars and evaluated against billing data is therefore a detective control wearing a preventive control’s clothes. The controls that actually bind before an agent commits money are denominated in resources rather than dollars — service control policies, service quotas, session-scoped IAM, and lease-bounded throwaway accounts — while dollar-denominated enforcement ships today only on the narrow surfaces where a single vendor owns both the meter and the gate — and even there it comes in two strengths worth keeping apart. Payment sessions like Amazon Bedrock AgentCore’s maxSpendAmount genuinely reserve against a ceiling before the spend happens. Inference gateways do not: they meter each response after it completes and refuse the next request, so the cap binds one call late. The difference is small for tokens and large for anything whose single-action cost is unbounded. The practitioner’s job for the next year is translating a dollar figure the business cares about into resource constraints the platform can refuse at request time.

Key Findings

1. The meter is a lagging control by construction, and the vendors say so in their own documentation

The most useful thing to establish up front is that this is not a tuning problem. AWS’s cost-management documentation is explicit that budget data refreshes at most three times a day, with roughly 8–12 hours between refreshes, and it carries a warning that reads like a description of the DN42 incident written in advance: “There can be a delay between when you incur a charge and when you receive a notification from AWS Budgets for the charge… You might incur additional costs or usage that exceed your budget notification threshold before AWS Budgets can notify you” (AWS Cost Management docs). InfoQ’s reporting describes Cost Explorer billing data as lagging around 24 hours, and contrasts it with the control-plane event log, noting that CloudTrail records a RunInstances or InvokeModel call within minutes while its cost surfaces in billing a day later (InfoQ). AWS’s own wording is worse than that shorthand, not better: Cost Explorer “refreshes your cost data at least once every 24 hours,” and because that depends on upstream billing applications, “some data might be updated later than 24 hours” (AWS Cost Management docs). There is a floor on refresh frequency and no published ceiling on the lag.

The practitioners InfoQ quotes land in the same place from different angles. Cloud architect and former AWS employee Magnus Eriksson: “Sadly AWS budget controls are not very efficient as billing is delayed 24h. True customer obsession should make AWS turn billing at least ‘semi realtime’.” Regula solutions architect Igor Zhdanko draws the distinction that makes generative-AI spend different in kind: “With traditional cloud resources, attackers still need infrastructure they can monetize. With GenAI APIs, stolen credentials can turn into thousands of dollars in usage almost instantly.” And AWS consultant Tobias Schmidt states the operating rule plainly: “We are all handing agents cloud credentials right now. Guardrails first, autonomy second.”

The consequence for control design is sharper than “alerts are slow.” It is that the gap between action and observation now exceeds the time an agent needs to exhaust a budget, which inverts the assumption every FinOps process is built on. Monthly reconciliation, anomaly detection, and budget alerting all assume the spender is a human or a human-paced system, so a day of drift costs a day of ordinary burn. An agent can compress a month of ordinary burn into an afternoon. The DN42 operator noticed in under 24 hours and still ended up four figures deep.

There is one native AWS control that looks like it closes this: budget actions, which can attach an IAM deny policy or a service control policy when a threshold trips. AWS documents that “after you set a threshold, configure a budget action to run either automatically or after your manual approval,” and that available actions include applying an IAM policy or SCP, or targeting specific EC2 or RDS instances (AWS Cost Management docs). This is the right shape — the remediation is a permission change, which is enforceable and immediate. But it inherits the meter’s latency: the threshold is evaluated against budget data on the 8-to-12-hour refresh cycle, and the optional manual-approval mode adds human latency on top. A budget action is a good late kill switch and a bad gate. Schmidt’s own recommendation after the $14K incident was exactly this pattern — a budget action that attaches an SCP to cut off Bedrock when costs spike — and it is worth having, on the understanding that it limits how long a runaway runs rather than whether it starts.

2. Stolen credentials and an over-eager agent are the same control problem

It is tempting to file the $14K incident under security and the $6,531 incident under agent safety, and to reach for different toolkits. That split is a mistake, and the two incidents landing in the same reporting window is what makes the point.

The Bedrock case was a compromise: static access keys on an EC2 instance, extracted by an attacker. Two defaults amplified it — the keys carried Bedrock full access, and Schmidt reports that AWS removed the model-access toggle in 2025, leaving all models enabled by default, so credentials intended for cheap experiments reached the expensive frontier models (Tobias Schmidt). The DN42 case involved no adversary. The operator handed an agent AWS credentials and a goal, and the agent did precisely what it was permitted to do, at a scale nobody had constrained. Its own account of the failure, relayed by the operator, was mundane: the same CloudFormation template deployed many times, duplicating instances and load balancers on each retry (Lan Tian).

Read as control problems these are one problem, because in both cases a credential with more authority than the task required met a spender with no rate limit. Whether the entity holding that credential is an attacker or a confused planner changes the incident narrative and changes almost nothing about the fix. That is why the preventive controls that work here are the boring identity ones. AWS’s own guidance on agent access to cloud resources leads with a principle that generalizes cleanly across both threat models: “Design permissions based on the acceptable scope of impact, not intended functionality alone” (Riggs Goodman III, AWS Security Blog, April 2026). The same post recommends per-agent execution roles, session policies that intersect with the role’s permissions at AssumeRole time, session tags marking a session as AI-driven, and IAM condition keys (aws:ViaAWSMCPService, aws:CalledViaAWSMCP, aws:PrincipalTag).

Be precise about what those keys actually distinguish, because it is easy to over-read them as an agent-versus-human identity signal. They mark calls that arrived through an AWS-managed MCP server. AWS is explicit that this is a path property, not a principal property, and documents the bypass in the same breath: when a caller reaches the API directly, “the request bypasses MCP servers entirely. The aws:ViaAWSMCPService condition key isn’t set.” AWS names the limit itself — “this is a scope boundary. Differentiation controls secure the MCP access path” (AWS Security Blog). An agent with shell access, an SDK, or code execution calls AWS directly and carries no such key; a human working through an MCP-mediated tool does. So these keys are useful for governing the MCP path and useless as a general agent detector — which means differentiation only holds if you also prevent or separately govern direct credential and SDK access.

The most instructive detail in the DN42 aftermath is the operator’s own remediation, sent to the project mailing list: “i have stopped the agent, the cost too high and much charges on card. pls merge the PR and i will start a new small agent and give it only a restricted aws key for peering and max 100mbps strict scanning limit” (Lan Tian). Nobody had to explain the architecture to them. Under financial pressure, the fix they reached for was credential scoping plus a resource cap — not a budget alert. That is the right instinct, and it is the instinct the tooling should be making cheap.

3. What actually binds before the action is denominated in resources, not dollars

Here is the uncomfortable shape of the current landscape. The controls that reliably refuse an agent’s request at request time are the ones that never mention money:

Service control policies. An SCP is evaluated on every API call in the affected organizational unit and can deny an action outright. Because it is attached above the account, in the organization, the principal it governs cannot remove it.
Service quotas. AWS’s Well-Architected guidance describes these as existing “as operational guardrails, to prevent accidentally provisioning more resources than you need” (REL01-BP01), and the EC2 documentation is blunt about the mechanism: “If you attempt to exceed the quota for a resource, the request fails” (Amazon EC2 service quotas). A regional on-demand vCPU quota set to something a human would find inconveniently low is a cheap and unusually direct defense against the DN42 failure mode: the five m8g.12xlarge instances would simply not have launched.
Session-scoped IAM. Short-lived credentials with a session policy narrowing the role’s permissions for a single tool invocation, per the AWS agent-access guidance above.

None of these can express “spend no more than $200.” They express “you may not launch that instance family, in that region, in that quantity.” Translating the first into the second is engineering work that no vendor currently does for you, and it is lossy in both directions — a quota generous enough for legitimate work still permits a lot of money, and a quota tight enough to bound cost will eventually block something real.

That translation gap is where the practitioner literature has concentrated, because it is where the pain is. BaristaLabs’ Sean McLellan frames the rule as a coverage test — if an agent can reach something metered, the metered thing needs a runtime guard — and prescribes a seven-part circuit breaker: budget caps per run and per hour, loop limits on retries and tool calls, explicit allow-lists of external services, human approval points, kill switches that revoke credentials, receipt logs, and a named owner for rollback (BaristaLabs, June 2026). A companion write-up makes the same argument with more bite, and its formulation is the one worth quoting to a skeptical stakeholder: “An agent with a vague goal, cloud credentials, network ambition, and no spend circuit breaker is not an autonomous engineer. It is an unbounded purchasing process with a chat interface” (Developers Digest, June 2026). Its four prescriptions — mandatory dry-run approval before provisioning, enforced ceilings on total and hourly spend, credential scoping to sandbox accounts with narrow roles and lowered quotas, and a cost circuit breaker that revokes credentials and cleans up on breach — are a reasonable starting specification.

The FinOps vendors describe the same layering with different vocabulary. Finout’s prescription is four tiers — per-request token limits, per-session budgets, per-day ceilings by agent type, and automatic termination when a threshold trips, with circuit breakers that pause agents exceeding parameters (Finout, June 2026). The interesting part is that it is a convergence: three independent write-ups, none citing each other, decomposing the problem the same way.

All three are vendor-adjacent practitioner posts rather than field-tested platform documentation, and none reports operating results. Treat them as a design checklist, not evidence. The value is that they independently arrive at the same decomposition: a level cap and a rate cap are different controls, and most teams ship only the first. A monthly ceiling constrains how bad a month can get; it does nothing about how bad an hour can get, which is the failure mode both 2026 incidents exhibit.

The one place a dollar figure can be evaluated before a cloud action is the plan. Infrastructure-as-code cost estimation — Infracost being the established tool — parses a Terraform, CloudFormation, or CDK plan against provider pricing and produces a monthly estimate before anything is applied, with policy guardrails available in its hosted tier and dedicated skills shipped for Claude Code, Cursor, and other coding agents (Infracost). That is a genuine pre-authorization signal for the provisioning path, and pairing it with a hard fail on a cost delta is the closest thing to a dollar-denominated gate available to an agent doing IaC work. Its limits are worth naming: it estimates monthly run-rate, not the burst cost of a retry loop, and it only covers changes that flow through a plan. An agent calling RunInstances directly, or invoking Bedrock, never touches it.

4. The blast-radius container is the pattern that actually shipped

If dollars can’t gate the action, the next best move is to make the action’s maximum consequence small and reclaimable. Unlike the controls above, it has an AWS-published reference implementation behind it — though not one built with agents in mind.

Innovation Sandbox on AWS automates the lifecycle of temporary, governed accounts: a user takes a lease on an account with configured budget and duration thresholds, service control policies attached to the account’s organizational unit “prevent sensitive, expensive, or difficult to clean up services and resources from being used by sandbox users,” and the solution monitors leases for “breaches in configured lease budget and duration thresholds.” On breach it can “automatically freeze accounts when they reach time or budget limits, preserving work while preventing additional spend,” and expired leases route through a cleanup pipeline that deletes user-created resources via AWS Nuke, quarantining the account for manual remediation if anything survives (AWS Solutions). The solution reached version 1.2.14 in July 2026, and AWS’s listed customer stories are universities and hackathons rather than agent fleets.

The mapping to credentialed agents is close enough to be useful and imperfect enough to be worth stating carefully. What transfers cleanly: one blast-radius container per agent or per run; SCPs denying the expensive service surface, evaluated pre-action and unmodifiable from inside; automatic freeze on a budget or duration threshold; automated teardown so an abandoned run does not keep billing. What does not transfer: the freeze trigger reads the same lagging billing data as everything else, so a container’s budget freeze is a bound on how long the overspend runs, not on whether it happens. The duration threshold is the more reliable of the two, because wall-clock is observable in real time. For an agent whose worst-case burn rate you can estimate, a tight lease duration is a better proxy control than a budget threshold — you are converting a dollar limit into a time limit, which the platform can actually enforce.

The per-agent-account pattern also solves a problem the identity layer alone does not: attribution. When each agent run holds credentials scoped to its own account, the cost report answers “which run did this” without tagging discipline, and revocation is a single account-level operation rather than a hunt through IAM.

5. Real dollar-denominated pre-authorization exists — where one vendor owns both the meter and the gate

There are production systems today that enforce a dollar ceiling before the spend happens rather than after. They share a structural precondition: the same party operates the billing meter and the request path, so the check is a local lookup rather than a query against an eventually-consistent billing pipeline.

Payment sessions. Amazon Bedrock AgentCore added Payments in preview, letting agents pay for x402-priced APIs, MCP servers, and paywalled content through embedded Coinbase or Stripe/Privy stablecoin wallets. The control primitive is the one that matters here: “Each PaymentSession has a configurable budget limit (maxSpendAmount, currency) and an expiry time. When the session expires or the budget is reached, further payment requests are denied. If a payment signing fails after budget deduction, the budget does not deduct the failed payment” (AWS AgentCore docs). That is a genuine hard cap evaluated at request time, with sensible refund semantics on failure, and AWS’s own framing acknowledges the gap it fills — that developers have been building governance frameworks and budget controls from scratch to prevent runaway spending. The scope is narrow by design: it governs what the agent purchases through the payment service, not what it provisions with its IAM credentials. An agent could hold a $10 PaymentSession and still launch $6,000 of EC2.

Inference gateways — with an important asterisk. The Claude Apps Gateway, a self-hosted control plane for Claude Code and Claude Desktop, carries spend caps as one of five core responsibilities. Anthropic’s description: “The gateway allows you to set daily, weekly, and monthly spend limits. Limits can be applied per organization, group, or user” (Anthropic).

The asterisk is that this is not pre-authorization in the sense used above, and the documentation is unambiguous about it. Metering happens after the fact — “after each response, a usage meter reads token counts off the response as it streams to the client, prices them at USD list price, and increments Postgres counters” — and enforcement lands on the following request: “when a developer passes their cap, the gateway returns 429 on their next request and blocks them until the period resets or an admin raises the cap” (spend limits documentation). The gateway checks recorded spend before admitting a request, then prices the result afterwards. The request that crosses the cap completes and is paid for; the next one is refused. Enforcement also fails open by default if the Postgres pre-check times out, unless enforcement.fail_closed_on_error is set.

So the correct classification is post-response metering with next-request enforcement, bounded overshoot of one request. That is still a categorical improvement on billing-data budgets — the loop closes in milliseconds rather than 8–12 hours, which is the difference between overshooting by one call and overshooting by a day — but it is not a reservation against a ceiling, and it should not be filed alongside AgentCore’s payment sessions. For tokens the distinction is usually academic, since a single call’s worst-case cost is bounded; §7 explains why the same property is far less comfortable for cloud resources. The open-source equivalent is more granular still and works the same way: LiteLLM enforces budgets across virtual keys, users, teams, end-customers, and tags simultaneously — its documentation is explicit that a key belonging to a team is gated against both the team budget and the user’s personal budget — rejects over-budget requests with an ExceededBudget error, and accepts budget windows down to seconds, so a key can carry stacked hourly and monthly limits that reset independently (LiteLLM docs).

Platform spend limits. Anthropic’s Spend Limits API, available to Claude Enterprise organizations, resolves an effective monthly limit per member from a hierarchy of per-user override, group, seat tier, and organization default, and pairs it with a request-and-approve workflow for increases (Anthropic). The design is thoughtful about the human loop — a member clicks “Request more usage,” an admin approves with an amount, and the approval writes the override in one call. It is also, by its own documentation, monthly-only: “Currently monthly is the only supported period; monthly spend resets at 00UTC on the first of each calendar month.” A monthly cap is a fine budget-governance instrument and a weak runaway control, for the same reason a monthly speed limit would be. This is the level-versus-rate distinction again, visible in a shipping product.

The general point about gateways as the enforcement locus is now being made outside the agent-security literature. Forbes’ Janakiram MSV, writing in July 2026, characterizes agent gateways as becoming the enterprise control plane precisely because organizations otherwise end up with dozens of agents hitting production systems directly and no single place to see or stop the traffic — with per-agent and per-team token metering named as a first-class gateway function alongside auth, rate limiting, and tool-permission filtering (Forbes). The consolidation is real. What it does not yet cover is the credentialed agent acting directly against a cloud API, which is the case both mid-2026 incidents describe.

6. The ceiling has to be one the governed party cannot raise

A spend cap is only a control if the entity it constrains cannot edit it. This sounds obvious and is routinely violated.

The clearest documented instance comes from OX Security’s research into AI-platform budget controls, disclosed in December 2025. Their finding on Cursor was that a non-admin team member could modify the organization’s spending limit without admin approval or notification — the write-up traces it to a user who exhausted a monthly budget in hours and then discovered he could raise the organization’s limit past a million dollars himself, and demonstrates a proof-of-concept where a malicious deeplink raises the limit and drives request loops up to the modified ceiling. On the Bedrock side, the same research notes that no mandatory spend cap is enabled by default and reports that AWS pointed to Service Quotas and Budgets as the customer-managed answer, declining to treat the issue as a security matter (OX Security). Whether AWS’s position is defensible is a separate argument; what matters operationally is that a cap living inside the tenant, editable by the tenant’s least-privileged member, is a suggestion.

This is the same structural argument the agent-authorization research has been making about tool-call permissions — that enforcement inside the component you cannot trust is not enforcement — arriving at the spend surface. The July agent-authorization wave established the principle for actions: put the decision somewhere the agent’s context cannot reach. Spend is the same shape with a different unit. Practically, it means the spend ceiling belongs one level above whoever might want to raise it: an SCP in the management account rather than an IAM policy in the member account, a gateway-side limit rather than a client-side configuration, a platform admin’s approval workflow rather than a self-service toggle.

Anthropic’s Spend Limits API is a decent illustration of getting this right by construction — the API writes per-user overrides only, and seat-tier, group, and organization defaults are configurable solely through organization settings, not through the API a workload might hold a key for. AgentCore’s maxSpendAmount is set on session creation by the caller that provisions the session, not by the agent consuming it.

7. The research names the constraint the products avoid: enforcement is post-hoc within an action

The academic work on resource-bounded agents is early and thin on deployment evidence, but one paper is unusually honest about the limit that every product in this space quietly inherits.

Agent Contracts: A Formal Framework for Resource-Bounded Autonomous AI Systems (Qing Ye and Jing Tan, submitted January 2026, revised March) extends the 1980 Contract Net Protocol metaphor from task allocation to resource-bounded execution. Its abstract states the gap directly: modern agent protocols standardize connectivity and interoperability, yet none provide formal resource-governance mechanisms to bound how much agents may consume or how long they may operate. The contract binds a multi-dimensional budget vector — tokens, API calls, iterations, web searches, compute time, and external cost in USD — and the paper’s distinctive contribution is conservation laws ensuring that budgets delegated to sub-agents respect the parent’s constraints, which is the mechanism a multi-agent system needs if a supervisor’s $50 ceiling is not to become $50 per branch (arXiv 2601.08815).

Its motivating case is the third public data point in this pattern, and it predates both cloud incidents: “In late 2025, an engineering team deployed a multi-agent research system with four specialized agents. Two agents fell into a recursive clarification loop, running undetected for eleven days. When the invoice arrived, the team discovered a $47,000 API bill.” The diagnosis is a one-liner — the system had no stop conditions, no budget limits, and no real-time cost monitoring (arXiv 2601.08815, full text).

The candid part is the enforcement discussion. The framework uses two layers: budget-aware prompting so the agent can self-regulate, which the authors treat as best-effort, and an external monitor that halts execution structurally when a constraint is breached. But because token consumption is not known until a generation completes, the hard layer is post-hoc within an action — it can stop the next call, not the current one. Reported results are a 90% token reduction with 525× lower variance in iterative workflows and zero conservation violations in multi-agent delegation (arXiv 2601.08815) — the paper’s own benchmark figures on its own harness, not independent replication.

That “stop the next call, not this one” property is exactly the constraint that governs how tight a spend gate can be, and it is worse for cloud resources than for tokens. A single language-model call has a bounded worst-case cost, so post-hoc halting bounds overshoot to roughly one call’s worth. A single CreateStack call has an essentially unbounded worst-case cost, and the DN42 agent’s failure was one such call repeated. This is the technical reason cloud-resource spend needs the permission boundary rather than a spend monitor: the monitor’s granularity is an action, and one action is enough.

The adjacent research is worth knowing about but does not close this. Runtime Governance for AI Agents: Policies on Paths (Maurits Kaptein, Vassilis-Javed Khan, Andriy Podstavnychy) argues that “the execution path is the central object for effective runtime governance” and formalizes compliance policies as functions from agent identity, partial path, proposed next action, and organizational state to a violation probability — with the useful observation that both system prompts and static access control are special cases, the former shaping the distribution over paths without evaluating them and the latter evaluating policies that ignore the path entirely (arXiv 2603.16586). It is a good frame for path-dependent authorization. Its abstract addresses legal, data-breach, and reputational cost, not monetary spend — cost governance would be a natural instantiation, and nobody has written it.

Practical Implications

Sort your existing spend controls into “refuses the request” and “tells you afterward,” and count. This is a half-day exercise with a high hit rate. Budgets, budget alerts, Cost Anomaly Detection, cost dashboards, and tag-based showback all land in the second column. Service control policies, service quotas, session policies and permission boundaries, gateway spend caps, and payment-session limits land in the first. Most teams that believe they have spend governance for agents have a first column containing nothing. Budget actions are the ambiguous case — categorize them as second-column, because the trigger is billing data.

Set the vCPU and instance-family quotas in any account an agent can reach to something a human would find annoying. The regional on-demand vCPU quota does more work against the DN42 failure mode than any budget you could configure, because it fails the RunInstances call rather than reporting it. Pair it with an SCP denying the instance families and regions the workload has no business using. Neither control knows what a dollar is, and both would have prevented the incident.

Give each agent run its own account, and lease it with a duration limit as well as a budget. Innovation Sandbox on AWS is the closest shipped reference for the lifecycle — provision, attach SCPs at the organizational-unit level, monitor lease thresholds, freeze on breach, nuke and recycle on expiry — and the pattern transfers even if you build it yourself. Weight the duration threshold more heavily than the budget threshold: wall-clock is observable in real time, spend is not. If you can estimate an agent’s worst-case burn rate, a lease duration is a dollar limit the platform can actually enforce.

Kill static credentials for anything an agent touches, and scope what remains per invocation. Both the $14K compromise and the wider guidance point the same way: per-agent execution roles, short-lived credentials, session policies that intersect the role at AssumeRole time, and condition keys governing the MCP access path — remembering that those keys secure that path rather than identifying agents in general, so direct SDK and shell access needs closing separately or the distinction leaks. Also audit the model-access surface specifically — the Bedrock incident was amplified by full-access keys reaching every model by default, and a credential intended for a cheap model that can call an expensive one is a spend control with a hole in it.

Put a plan-and-estimate gate in front of any agent that provisions infrastructure. If the agent’s provisioning path runs through Terraform, CloudFormation, or CDK, run the plan through cost estimation and fail the run on a threshold breach before apply. Infracost ships agent-facing skills for exactly this workflow. Treat the estimate as a monthly run-rate signal, not a burst-cost bound — it will catch “this agent wants five 48-vCPU instances” and will not catch “this agent will retry the same stack forty times.”

Add a rate cap wherever you have a level cap. A monthly ceiling is the wrong instrument against a one-day runaway, and several shipping products only offer monthly. Where the tooling supports stacked windows — LiteLLM’s per-key budget durations from seconds upward is the clearest example — set an hourly or per-run limit alongside the monthly one. Where it doesn’t, the rate cap has to come from somewhere else: quotas, lease duration, or a loop counter in the harness.

Confirm nobody inside the boundary can raise the ceiling. Walk the actual permission path for every spend limit you rely on and ask who can edit it. If the answer includes the agent’s own credentials, an ordinary team member, or anything running inside the account being governed, it is not a ceiling. The Cursor finding is the cautionary case: a real spend limit, in a real product, editable by the people it constrained.

Instrument on control-plane events, not on the bill. CloudTrail sees RunInstances and InvokeModel within minutes; billing sees them a day later. If you want detection that is merely slow rather than useless, alert on provisioning-event patterns — burst counts, expensive instance types, repeated stack operations — and accept that this is still detective. It buys you hours off the response clock, which in both 2026 incidents would have been the difference between four figures and three.

Open Questions

Will any hyperscaler ship a real-time spend meter, or is the lag architectural? The practitioner complaint quoted in InfoQ’s reporting — that billing should be at least semi-real-time — is the obvious ask, and no provider has committed to it publicly. Whether the 8-to-12-hour refresh is a product decision or a consequence of how usage records are aggregated across services and regions has not been explained in vendor documentation, which makes it hard to know if this problem has an expiry date or is permanent. Plan as though it is permanent.
Does a dollar-denominated pre-authorization primitive for general cloud actions emerge, and from where? AgentCore Payments proves the shape works when one party owns the meter and the gate. Extending it to RunInstances would mean pricing an arbitrary API call at authorization time and holding a reservation against a budget — technically plausible, since the pricing catalog exists and Infracost demonstrates that plans can be priced, but it would require the provider to make the check part of the authorization path. No provider has publicly signaled an intent to build it.
How do delegated budgets survive multi-agent fan-out in practice? The conservation-law idea in the Agent Contracts work is the right formalism, and it is validated only on the authors’ own harness. The orchestration frameworks in common use do not, on their public documentation, ship a budget ledger that decrements across a delegation tree — a supervisor can spawn sub-agents whose combined spend exceeds its own allowance. Whether this becomes a framework feature (LangGraph, CrewAI, Agents SDK) or stays a bespoke concern is genuinely open, and it decides whether “the run costs at most $50” is a statement a team can make.
Where does spend enforcement sit relative to action authorization? Two enforcement layers are being built in parallel: the tool-call authorization gateways surveyed in the agent-authorization boundary work, and the spend controls described here. They want the same interception point and the same policy language — Cedar can express “deny this action” as easily for cost reasons as for security reasons — but none of the products surveyed here evaluates both in one decision. Whether they converge into one policy layer or stay separate is the architectural question a team standing up a gateway today has to guess at.
What is the actual incidence rate? Three publicly-documented incidents across roughly nine months — $14,000, $6,531, $47,000 — is a suggestive pattern and a terrible dataset. Public reporting on how often agent spend runaways happen, and at what magnitudes, remains thin; the visible cases are the ones somebody chose to write about, which skews toward the embarrassing and the small-team. Whether enterprises are quietly absorbing larger versions is unknown from the outside.
Does the insurance-and-negotiation backstop hold? AWS reduced the DN42 bill from $6,531.30 to $1,894 after the operator explained the agent’s repeated deployments (Lan Tian; InfoQ). That is discretionary goodwill, not policy, and it is the informal control a lot of teams are implicitly relying on. How providers handle agent-caused overspend at scale — whether goodwill credits survive the pattern becoming common — has not been addressed publicly by any provider, and a team should not budget for it.

Sources

AI Agents with Cloud Credentials Are Outrunning Billing Guardrails Built for Human-Speed Mistakes — InfoQ, July 16, 2026
AI Agent Bankrupted Their Operator While Trying to Scan DN42 — Lan Tian @ Blog
A 3-person agency just got a $14k AWS bill in 1d — Tobias Schmidt, LinkedIn
Managing your costs with AWS Budgets — AWS Cost Management User Guide
Configuring budget actions — AWS Cost Management User Guide
Amazon EC2 service quotas — Amazon EC2 User Guide
REL01-BP01 Aware of service quotas and constraints — AWS Well-Architected Framework, Reliability Pillar
Secure AI agent access patterns to AWS resources using Model Context Protocol — Riggs Goodman III, AWS Security Blog, April 14, 2026
Innovation Sandbox on AWS — AWS Solutions, v1.2.14, July 2026
Amazon Bedrock AgentCore payments — AWS AgentCore Developer Guide (preview)
Introducing the Claude Apps Gateway — Anthropic
AWS Ships a Self-Hosted Deployment of the Claude Apps Gateway — InfoQ, July 15, 2026
Spend Limits API — Claude Platform Docs
Budgets, Rate Limits — LiteLLM Proxy documentation
Two Clicks to $1M: How Attackers Can Drain Enterprise Budgets Through AI Platforms — OX Security, December 9, 2025
Agent Gateways Are Becoming The Control Plane For Enterprise AI — Janakiram MSV, Forbes, July 5, 2026
AI Infrastructure Agents Need Spend Guardrails — Developers Digest, June 12, 2026
AI agent spend control needs a circuit breaker — Sean McLellan, BaristaLabs, June 12, 2026
Agentic AI Cost Governance: Controlling Spend Before It Controls You — Finout, June 7, 2026
infracost/infracost — GitHub
Agent Contracts: A Formal Framework for Resource-Bounded Autonomous AI Systems — Qing Ye, Jing Tan (arXiv 2601.08815; full text)
Runtime Governance for AI Agents: Policies on Paths — Maurits Kaptein, Vassilis-Javed Khan, Andriy Podstavnychy (arXiv 2603.16586)
Claude apps gateway spend limits — Claude Code documentation
What is AWS Cost Explorer? — AWS Cost Management User Guide