AWS Bedrock AgentCore Policy is now generally available. It solves the behavior governance problem — what your AI agents can access, which tools they can call, and what actions they're allowed to take. That's a meaningful step forward.
But it leaves a different problem untouched: what your agents are spending, which agent is responsible, and what stops a runaway loop before the bill arrives.
Behavior governance and spend governance are two distinct control layers. Both are required. One is now solved. This post covers the one that isn't.
Why AWS Native Cost Attribution Isn't Enough
AWS shipped per-IAM-principal cost attribution for Bedrock on April 17, 2026. It flows automatically into Cost Usage Reports (CUR 2.0) and Cost Explorer. This is a genuine improvement over no attribution at all.
The limitations are two-fold.
First, attribution arrives with a 24-48 hour lag. By the time Cost Explorer shows a spending spike, the tokens have already burned. If an agent enters a runaway loop at 9 AM, you see the evidence the next morning. The invoice is already written.
Second, attribution is at the IAM-principal level — not the individual agent level. If a single IAM role runs twelve Bedrock agents, AWS Cost Explorer tells you the IAM role spent $4,200 this week. It doesn't tell you which of the twelve agents ran overbudget, which task triggered the anomaly, or which workflow produced the spike. The granularity stops at the boundary of your IAM design.
For teams with one agent per IAM role, this is manageable. For teams running production AI systems with multiple agents per IAM role — the common architecture — IAM-level attribution is an incomplete picture.
What Happens When There Is No Cost Ceiling
The documented failure mode is not theoretical. A specific scenario has surfaced in the AWS Bedrock engineering community: an agent enters a loop with no API available to force-terminate the session. Tokens burn until the container dies on its own timeout. There is no kill switch. There is no ceiling. The only resolution is natural container expiration.
This is not a Bedrock bug — it is an architecture gap. Bedrock is designed to run agents. It is not designed to stop an agent at a spend threshold before the bill materializes. That control layer has to be added separately.
Without a proactive spend ceiling, the cost governance posture is: discover, then react. AWS Cost Explorer alerts fire after the anomaly is already in the billing record. The response is a post-facto invoice conversation, not a prevention workflow.
The Three Layers of Bedrock Cost Governance
A complete cost governance posture for AWS Bedrock requires three distinct capabilities:
- Attribution — knowing which agent spent what, at sub-IAM-principal granularity, in near real time. IAM-level attribution with a 24-48 hour lag handles the reporting layer. It does not handle the operational layer.
- Enforcement — a budget threshold that stops an agent automatically when it hits a ceiling, before the invoice materializes. AWS CloudWatch and Budgets are reactive: they alert after the spend has happened. The proactive enforcement layer — a gateway that intercepts agent invocations and pauses execution at threshold — has to be built or bought.
- Forecasting — a model that projects 30-90 day Bedrock spend based on current consumption patterns, so engineering and finance can budget forward rather than reconcile backward.
Most teams have partial attribution, no enforcement, and no forecasting. A complete control plane requires all three.
The DIY Path: AWS Step Functions + Lambda + DynamoDB
AWS's own engineering team documented the proactive enforcement architecture in their October 2025 post "Build a proactive AI cost management system for Amazon Bedrock." The recommended stack: a Step Functions workflow wrapping Bedrock invocations, a Lambda function checking DynamoDB budget state before each invocation, and CloudWatch alarms triggering the pause logic.
This architecture works. It provides near-real-time enforcement by intercepting each Bedrock API call and checking a budget counter before execution proceeds.
It is also a multi-week engineering project. You need to design the Step Functions workflow, write the Lambda functions, provision the DynamoDB tables, wire the CloudWatch alarms, test the pause logic, and instrument each agent invocation through the gateway. Every new agent requires gateway wiring. For teams that need cost governance now rather than in six weeks, it is not a practical first step.
AgentSpendrix: The 5-Minute Alternative
AgentSpendrix ships the Step Functions gateway AWS recommends as a 5-minute CloudFormation install. No code changes required to existing Bedrock applications.
Per-agent attribution: AgentSpendrix tracks spend at the individual agent level — not just which IAM role called Bedrock, but which specific agent drove the cost. Attribution data is available in under 30 seconds, not 24-48 hours.
Agent auto-pause: When an agent reaches a configured budget threshold, AgentSpendrix pauses it automatically before the next invocation executes. The bill stops before the threshold is exceeded, not after.
Forecasting: 30-90 day spend projections with 80% accuracy, built from current consumption patterns.
| Capability | AWS Native | AgentSpendrix |
|---|---|---|
| Per-IAM-principal attribution | Yes | Yes |
| Per-agent attribution (sub-IAM level) | No | Yes |
| Attribution latency | 24-48 hours | Under 30 seconds |
| Proactive agent auto-pause | No | Yes |
| Budget enforcement timing | Reactive (alert after spend) | Proactive (pause before invocation) |
| 30-90 day forecasting | No | Yes |
| Implementation time | 4-8 weeks (DIY build) | 5 minutes (CloudFormation) |
| Code changes required | Yes | No |
Pricing starts at $299/month (up to 500,000 invocations). Deploy on AWS Marketplace — free trial available.




