The spend cap held. The risk budget didn’t compose.

The finding

I gave a payment agent a hard per-session spend cap and watched it hold. Each session, the agent proposed a bounded action, the cap evaluated it, and anything over the limit was refused. Working as designed.

Then I ran the scenario across five sessions. Each action stayed under its per-session cap. Every action was locally valid under the identity, delegation, and per-session rules presented to the evaluator: the agent’s identity verified, its delegated authority in scope, the per-call policy satisfied. Every check configured in the scenario passed — five times.

The authorized exposure — the sum of what those individually-valid actions were cleared to do — exceeded the aggregate risk budget the whole arrangement was supposed to respect. The missing aggregate constraint was simply never represented in any single decision’s context.

To be precise about what this is and isn’t: this sat at the authorization/signing layer, not settlement, and it is not a vulnerability in anyone’s product. It’s a class of gap, not a bug. Every control did exactly what it was built to do — evaluate one action against the rules it was handed. Nothing in the path was handed the aggregate.

The real architecture question

2026 has been the year agent governance shipped. Microsoft’s Agent Control Specification is a fail-closed decision runtime under an open license. Galileo’s Agent Control puts governed decision points before execution. AWS AgentCore enforces policy at the gateway, outside the agent’s code. These are real, and they’re good — together they show that runtime policy at the moment of action has become an established category. A year ago it was still emerging.

It’s tempting to say these engines “can’t do composition because they’re stateless.” That’s wrong, and it’s worth being precise about why — because the precise version is the stronger argument.

A stateless policy evaluator can absolutely enforce an aggregate-risk rule — if the surrounding architecture supplies the current aggregate in the decision snapshot. Microsoft ACS, for instance, accepts a complete snapshot on every call and supports custom dispatchers; the runtime retains no state, but the host around it can. Keeping the evaluator deterministic and stateless has real advantages. The evaluator was never the problem.

The problem is that something in the enforcement architecture must maintain a shared, authoritative view of what prior decisions have already consumed — and then feed that view into the decision. A composition control is therefore not “another rule.” It needs:

• a cross-session risk ledger — a shared, authoritative record of committed exposure;
• atomic reservation of aggregate capacity, so a decision consumes budget as it authorizes;
• reservation lifecycle and reconciliation, so capacity is committed, settled, released, or expired correctly when an action succeeds, fails, is cancelled, or times out — otherwise the control prevents overspending by eventually locking the whole budget forever;
• idempotency and cross-session correlation, so retries and parallel sessions don’t double-count or race;
• and a path that supplies the resulting aggregate into the decision context the evaluator sees.

A stateless engine can evaluate that snapshot. It cannot create a trustworthy snapshot by itself.

So the gap is not stateless PDP versus stateful PDP. It is isolated decision evaluation versus composition-aware enforcement. The engines shipping today are excellent at the former. The public descriptions of the platforms discussed here establish intervention-point and per-request policy evaluation; they do not establish a built-in cross-session risk ledger with atomic reservation. That ledger-plus-reservation architecture — not a cleverer rule — is the missing layer this scenario demonstrates.

None of these primitives is new. Payment, inventory, and quota systems have used reservation ledgers for years. The contribution here is to frame these established primitives as a first-class agent-governance control over what locally authorized actions compose into.

Concurrency is where this gets hard (and honest)

Here is the part that separates a real composition control from a running counter: a running total is not sufficient under concurrency. If five sessions evaluate in parallel, each can read the same pre-update total, each finds room under the budget, and all five pass before any update becomes visible. The naive counter allows the very breach it was meant to stop.

A correct composition control must atomically check and reserve aggregate capacity before authorizing the action — reserve-then-authorize, not authorize-then-increment — with idempotency so retries don’t inflate the ledger. That atomic reservation is precisely why this is an architecture problem and not a policy-rule problem.

A companion fixture makes the concurrency point directly. It runs the same five sessions two ways:

$ node scripts/eaa-lab.mjs run authorized-but-composed-race race.json
Naive counter: 5 AUTHORIZED (exposure 4000 > 3000 budget — BREACH)
Atomic reserve-then-authorize: 3 AUTHORIZED, 2 DENIED (reservation)
Evidence: replay-consistent | Classification: SYNTHETIC

Identical inputs, identical per-session policy. The naive running counter lets all five through because each session reads the same pre-update total before any write is visible; reserve-then-authorize serializes the reservations against one ledger and denies the two that would breach. Same rule, different architecture — which is the whole point.

The evidence contract is the second half of the point, and the sequential composition run is where it’s easiest to see what the control records:

$ node scripts/eaa-lab.mjs run authorized-but-composed composition.json
Local checks: 4 ALLOWED
Final decisions: 3 ALLOWED, 1 REFUSED
Halted before session 5
Evidence: replay-consistent | Classification: SYNTHETIC

$ node scripts/eaa-lab.mjs verify composition.json

Five sessions of 800 against a per-session cap of 1,000 and an aggregate budget of 3,000. Each evaluated action passes its own per-session check — the control carries the running exposure alongside it, allows the first three (committed exposure 2,400), and refuses the fourth: it clears its local check, but 800 more would compose to 3,200, past the budget, so the run halts on that first breach. Only a control supplied with the running exposure and the aggregate threshold caught what five isolated checks could not.

It emits a machine-checkable, replayable decision record: the prior allowed decisions, the running aggregate, the budget crossed, and the refused session. The included verifier replays the decision from the fixture and checks that the recorded aggregate, threshold crossing, and verdict are internally consistent. That is a real, useful property — internal-consistency replay — and it is not yet the signed, provenance-anchored proof that would let a third party trust the record without trusting the runner. Getting from “replayable and consistent” to “independently provable” is the accountability work that sits above this.

Why this is the layer that matters now

Adoption is moving faster than the control architecture. Gartner predicts that up to 40% of enterprise applications will include task-specific agents by the end of 2026, from under 5% in 2025. It also predicts that 40% of enterprises will demote or decommission autonomous agents by 2027 because governance gaps emerge only after production incidents. The question is no longer whether runtime governance will exist. It is whether that governance can reason across the decisions it has already allowed.

A year ago, governing agent behavior before execution was still an emerging category. ACS, Galileo Agent Control, and AgentCore show that runtime policy enforcement is now rapidly becoming established. The open layer this scenario targets is composition: the ledger, atomic reservation, reservation lifecycle, cross-session correlation, and the decision that consumes them. That’s not a feature you add to a rule set. It’s an architectural commitment.

The fifth domain

Composition control is not a replacement for identity, authorization, or per-call policy. It is the layer that consumes their decisions and asks what those decisions become together.

This is why the Enterprise Agent Architecture model treats the agent workforce as a fifth domain. It is not merely an application tier. It is a population of actors exercising delegated authority concurrently — and governing it means governing both the individual action and the aggregate state those actions create.

Sources

• Microsoft Agent Control Specification — agent-governance-toolkit (toolkit announcement, April 2026)
• Galileo, “Announcing Agent Control: The Open Source Control Plane for AI Agents” (March 2026)
• AWS, “Amazon Bedrock AgentCore now supports Bedrock Guardrails in policy” (June 17, 2026)
• Gartner, “40% of enterprise apps will feature task-specific AI agents by 2026”
• Gartner, “Applying uniform governance across AI agents will lead to enterprise AI agent failure” (40% demoted/decommissioned by 2027)

AI-assisted and human-reviewed. All scenarios are synthetic reference scenarios, not production telemetry, benchmarks, or evidence of general agent safety.