S1.2.2: Bounded Autonomy — A Reference Architecture

A reference architecture note for architects, security teams, and procurement leaders in regulated industries. It assumes the five bounded-autonomy primitives introduced in S1.2.1 and focuses on what to actually build, buy, or adopt to put them into production. It is structured for non-linear reading: take the conceptual view if you are deciding what the architecture is, the operational view if you are deciding how it runs, the technical view if you are deciding what to deploy, the implementation view if you are deciding how to wire it, and the build/buy section when the trade-offs need to be defensible to a steering committee.

Architecture in 60 Seconds

If you read nothing else, read this. The rest of the document is the justification.

• The agent is untrusted — assumed fallible and manipulable by design.
• The gateway is mandatory — every consequential call passes through it, and there is no path around it.
• Policy lives outside the model — grants, budgets, thresholds, and tiers are enforced in code the agent cannot reach, not asserted in a prompt.
• Human approvals become signed, action-bound tokens — “a human approved this” is a verifiable claim, not a comforting one.
• Budgets limit blast radius — value, volume, and velocity caps, reserved atomically.
• Audit records are immutable and attributable — hashes and tokens, not raw payloads; written before the action and recorded in the enterprise’s evidence system.
• The control plane fails static — a policy-distribution outage holds the last good policy; it never widens the perimeter.
• The data plane fails closed — no valid verdict, no durable audit acceptance, no action.

The single sentence the whole architecture rests on: correctness is a model-and-agent problem; containment is an architecture problem.

From Pattern to Architecture

S1.2.1 made one argument: bounded autonomy is a perimeter outside the model, not a prompt inside it. The boundary has to live somewhere the agent cannot reach — in code, it cannot rewrite, and in network paths, it cannot bypass — because anything within the model’s reasoning can be misunderstood, manipulated, or confidently ignored.

That post gave the pattern as five primitives under the mnemonic FT-LLM — Force the LLM:

• Force human approval above thresholds, with teeth (a verified, action-bound approval token — not a polite request in the system prompt).
• Treat actions by reversibility: reversible, irreversible-but-bounded, irreversible-and-unbounded, and scale the agent’s authority inversely.
• Limit the tools the agent can call, and know whose authority it is acting under (capability and identity scoping).
• Limit blast radius with action budgets across the three V’s: Value, Volume, Velocity.
• Make the agent stop, defer, or escalate when something is unclear — the RED triad (Refuse–Escalate–Defer), never fail open.

This post is the assembly guide. The primitives are the what; this is the how. And because “how” is the part that turns into a budget line, every component below carries an explicit posture: build it, buy it, or adopt-and-extend.

A note before the views: nothing here is novel computing. Privilege separation, capability-based security, transaction limits, four-eyes approval, and append-only ledgers — all of it predates AI by decades. What is new is applying it to a non-deterministic actor that you have given the keys to consequential systems. The architecture exists because consequential authority cannot depend on self-enforcement by the actor exercising it, and no amount of prompt-engineering changes can alter that.

The Architecture in Four Views

The same architecture looks different depending on the question you bring to it. Rather than draw one diagram that tries to answer everything and answers nothing well, this note separates four views:

• Conceptual — the logical components and how authority flows between them, independent of any technology. This is the view you pin to a wall.
• Operational — how it is deployed and how a single request flows through it in production, including what happens when parts of it fail.
• Technical — the concrete technology behind each logical component, with the build/buy posture for each.
• Implementation — the sequences, policy, and schemas you actually wire together: how a verdict is reached and recorded, and what the audit record and approval token contain.

A component that is a single box in the conceptual view may be three products in the technical view, and the operational view is where you discover whether the whole thing survives a regional outage. Keep the four separate, and you keep the conversation honest.

A running example

One scenario runs through every view below, so the abstract components have something concrete to hang on:

An AI payments assistant wants to pay ₹2,00,000 to a beneficiary it has never paid before. The gateway can see the tool being called, the principal it is acting for, the amount, the beneficiary, the current budget state, and whether a human has approved. It will refuse, allow, or escalate. The model can request the payment; it cannot authorise it. Hold this example in mind — each view shows a different face of how the architecture handles it.

Why does any of this machinery exist? Because the same assistant, without a perimeter, fails in a handful of predictable ways:

Each view below shows the control that closes one of these. The full threat model is tabulated near the end.

A mini-glossary

The piece is dense with access-control vocabulary. The seven terms that carry the most weight:

View 1 — Conceptual

The conceptual model has one organising idea — the perimeter — and one organising component — the action gateway. Everything else exists to make the gateway’s verdict correct, attributable, and durable.

The agent sits in an untrusted reasoning zone

The agent (and the framework that orchestrates it) is treated as fallible and manipulable by design. It is not the enemy; it is simply not trustworthy enough to hold consequential authority, just as a junior employee is not the enemy but does not get the wire-transfer signing key without a perimeter (safety-net). The architecture’s job is to let the agent reason freely while ensuring its reasoning cannot, on its own, produce a consequential action.

The action gateway is the single chokepoint

Every consequential call the agent wishes to make passes through the gateway, and there is no other path. This is the load-bearing property of the whole design: if the agent can reach a tool by any route that skips the gateway, the perimeter has a hole, and the architecture is decorative. Inside the gateway sit three classic access-control roles:

• PEP — Policy Enforcement Point. The component that physically intercepts the call and either lets it through, blocks it, or holds it (pending escalation). The PEP enforces; it does not decide.
• PDP — Policy Decision Point. The component the PEP asks for a verdict: allow, deny, or escalate. The PDP holds the policy and the logic; it does not touch the call itself.
• PIPs — Policy Information Points. The read-only context the PDP needs to decide on includes the principal and workload identity, the current action-budget state, the signed tool grants in force, and any approval tokens already issued. From the PDP’s point of view, these are read-only sources of decision context (not equal to stateless or immutable, just read-only for PDP); some of the underlying stores — the budget ledger in particular — are still written by the gateway, but only through controlled, atomic paths (see the budget reservation discussion in View 4), never by the PDP during evaluation.

Separating enforcement, decision, and information is not academic tidiness. It is what lets you change a policy without redeploying the proxy, audit a decision without trusting the enforcer, and reason about each failure mode in isolation.

The control plane governs policy as code

To the left of the gateway, the control plane is where policy is authored, reviewed, version-controlled, signed, and distributed to the PDPs. In a regulated environment, the control plane is itself a controlled artefact: a policy change is a change-managed event with an approver, a diff, and a rollback. The control plane’s defining operational property is that it fails static — if it goes dark, the PDPs keep enforcing the last good signed policy. A control-plane outage must never widen the perimeter.

The audit fabric makes every decision reconstructable

To the right, the audit fabric receives an immutable, attributable record of every decision and action: a hash and a reference to the inputs (the raw payloads and any PII live in separate, tighter-controlled stores — tokenised, never written inline), the verdict, which component produced the verdict (gateway policy vs the agent’s own logic — the source matters for triage), the identity in play, the grants and budget state at the time, and a cryptographic anchor that makes tampering evident. Note the word: tamper-evident, not tamper-resistant. You are not claiming the record cannot be altered; you are guaranteeing that any alteration can be detected. That is the achievable and the defensible claim.

One framing point that the Audit Trail Pattern (S1.1) makes, and that this architecture inherits: the audit fabric is the regulated entity’s system of record, not the bounded-autonomy system’s private ledger. The gateway is a producer into the enterprise fabric — it signs its records at source with its own workload identity and ships them across the trust boundary — it does not own them. Drawn as a box in this diagram, the audit fabric is really the enterprise’s, and the gateway is simply another compliant producer feeding it.

The human review system closes the escalation loop

Below the audit fabric, the human review system is where escalations land. An authorised reviewer — with the actual authority for the decision class — acts on the escalation and, on approval, the system issues a signed, action-bound, non-replayable approval token back to the gateway. The token is bound to specific action parameters, so it cannot be reused for a different transfer, and it records the reviewer’s identity and review duration, making “a human approved this” a verifiable claim rather than a comforting fiction.

The tool layer lives behind the perimeter

At the bottom, the tools — MCP servers, native APIs, and internal systems of record — are reachable only through the gateway. And the gateway is deliberately humble here: it is a complementary control plane, not a replacement. A bank’s payment API already runs fraud detection, AML screening, sanctions checks, and velocity controls. The gateway does not re-implement any of that. It adds only the agent-specific controls that those systems cannot see — that the caller is an AI agent, that it is running where it is supposed to, that this action is within session intent — and defers to the existing systems for everything that has always been their job.

One caveat on classification: reversibility is not the only axis that matters. A tool can be perfectly reversible and still consequential if it reads sensitive data—such as salary, PHI, claims history, sanctions lists, or customer PII. A read that cannot be undone but can be exfiltrated is a real risk class. Tool classification, therefore, needs a second dimension alongside reversibility: data sensitivity and exfiltration risk, governed by read scopes, egress controls, and response filtering, not just by whether the action can be rolled back. And a practical note on the reversible tier itself: in enterprise systems, “reversible” usually means a compensating transaction, not a physical rollback. Most systems of record — ledgers, EHRs, event stores — are append-only by design, so undo means posting a compensating entry (a reversal, a credit, a correction), not deleting the original. Designing reversible actions as compensations keeps the audit trail intact, which is the whole point.

View 2 — Operational

The conceptual view tells you what the components are. The operational view tells you whether they survive contact with production.

Topology: a slow global tier over fast regional data planes

The deployment splits by change rate and by data residency.

The global control tier holds the things that change slowly and must be governed centrally: policy authoring and signing, the identity authority, and the immutable audit ledger. It is low-traffic, high-assurance, and change-managed.

The regional data planes hold the things that must be fast and local: a gateway with a co-located PDP (so a policy verdict is a low-latency, local verdict, not a network round-trip you pay on every action), the PIP state stores for budgets and grants, and a durable regional audit sink that the gateway writes to synchronously and that then forwards to the global ledger asynchronously. The distinction matters and resolves an apparent tension between this view and the implementation view: the synchronous ack the gateway waits on is from the local durable, append-only regional sink; the global anchoring happens asynchronously. If the regional sink cannot durably accept the record, the action fails closed. If only the global hop is lagging, the action proceeds — the local record already exists and will anchor when the link recovers. Co-location of the PDP matters for the same reason: a remote PDP turns every tool call into a synchronous dependency on a shared service — exactly the kind of latency and blast-radius coupling you are trying to avoid. Note that low-latency is the honest claim, not sub-millisecond: the verdict is fast when the policy and cached context are in-process, but any PIP lookup that touches Redis or Postgres on the request path adds time.

For regulated workloads with data-residency obligations (E.g., Russia: Federal Law 242-FZ; India: RBI payments data rule), the regional split is not an optimisation; it is a requirement. Budget and grant state stays in-region. As for the audit record: even tokenised decision metadata can be residency-sensitive, so the egress posture is a deliberate choice, not a default. Depending on the obligation, either the full audit record remains regional and only the Merkle roots are globally anchored, or tokenised decision metadata is exported to the enterprise ledger while raw payloads and PII never leave the region. The architecture supports both; the residency regime decides which.

Two failure semantics

This is the single most important operational distinction in the architecture, and it is the one most often got wrong:

• The data plane fails closed. If the gateway cannot obtain a valid verdict — PDP unreachable, PIP lookup times out, identity cannot be verified — the action does not happen. No verdict, no action.
• The control plane fails static. If the control tier is unreachable, the regions keep enforcing the last good signed policy. Policy distribution being down must never cause the perimeter to open or to start denying legitimate traffic wholesale.

The request lifecycle

A single tool call moves through five steps. (1) The agent calls a tool with an intent and parameters. (2) The PEP intercepts — nothing passes uninspected. (3) The PDP evaluates against budgets, grants, thresholds, and the action’s reversibility tier, reading PIP state as needed. (4) A verdict is produced. (5) One of three things happens:

• Allow → the call reaches the granted tool or API, and the result returns to the agent.
• Escalate → the call is held while a human reviews. The hold is not a thread blocked in memory; it is a durable state (more on this in the technical view), because a human may take minutes or hours, and the workflow must survive a process restart in the meantime. Upon signing the approval token, the workflow resumes.
• Refuse → the action is blocked, because there is no token, no budget, or no grant, and the refusal is recorded.

Every one of these steps writes to the audit. The audit spine is not an afterthought bolted on at the end; it runs the length of the lifecycle.

Day-2 operations: read refusals as health

The operational discipline that separates teams who keep their perimeter from those who quietly dismantle it lies in how they read the dashboards.

In production, the limits will fire. Budgets will deplete, thresholds will trip, refusals will appear. A team that has internalised the architecture reads a steady refusal rate as the system working — the agent met something its perimeter said it should not handle, and the perimeter held. A team that reads refusals as defects starts lowering thresholds to make the dashboard quieter, and within a quarter, the perimeter becomes a formality.

So instrument for the right things: refusal rate by reason (budget vs grant vs threshold vs identity), escalation rate and reviewer response time, and — critically — the escalation approval rate. A reviewer approving 200 escalations a day, each in 90 seconds, is a rubber stamp with a paper trail, and your audit will show it. The architecture can force escalation; only your operating model can make the review meaningful.

Operating responsibilities

The components do not share an owner, and pretending they do creates gaps. In practice: the platform/security team owns the gateway and identity; a governance or risk function owns policy authoring in the control plane (with engineering implementing it as code); the business/operations function owns the human review queue and the reviewer authority model; and a compliance or audit function owns the ledger and its retention. The architecture works only if each of these owners actually exists and is accountable.

Break-glass

Regulated systems need an emergency path, and the dangerous instinct is to build break-glass as a bypass of the gateway “for when things are really broken.” That instinct must be resisted: break-glass must never mean bypassing the perimeter or the audit. It means switching the gateway into a distinct, pre-authorised emergency authority mode — one that is, if anything, more heavily recorded and reviewed, not less. What it does not do is change whether the gateway mediates. The direction of the change in authority, though, depends on the emergency and differs sharply by domain.

In healthcare, during an emergency, care providers need elevated access. A clinician needs to read a record they would not normally be entitled to — an unconscious patient, an unfamiliar ward, seconds that matter. Here, break-glass elevates: it broadens the reading scope for speed and life safety. It still does not skip the gateway; the access remains mediated, is stamped with a break-glass marker, and is routed to mandatory after-the-fact review — because the risk being managed is a patient harmed by data withheld.

In BFSI, emergencies usually run the other way: money moves when it should not — a suspected compromise, a surge in fraud, a runaway agent. Here, break-glass restricts: it pulls back the agent’s automated authority — narrowing grants and budgets, forcing every action to human approval, or halting the agent outright — because the risk being managed is over-action, not under-access. Where a human must still act urgently under that posture (releasing a legitimate high-value payment against a settlement deadline, say), that is a separate, time-boxed, dual-controlled human authority path with its own reviewer class — not a relaxation of the agent’s.

View 3 — Technical

Now, the concrete technology. The posture markers — adopt, buy, build, build-on-managed — are the heart of this view, and they roll up into the build/buy section that follows.

The gateway is best realised as a reverse-proxy data plane — Envoy, NGINX, or a purpose-built proxy — with the PEP implemented as a filter in the proxy’s chain. Adopt and extend. The reason it must be a proxy and not an in-process SDK is the invariant from View 1: an out-of-process proxy on the network path is something the agent cannot link around, monkey-patch, or talk its way past. An SDK the agent imports is inside the agent’s blast radius, and the whole point was to put authority outside it. One caveat that is easy to miss: a proxy is only a perimeter if direct tool egress is technically denied. If the agent’s runtime has open egress, it can simply skip the proxy. The proxy must be backed by network and platform controls that ensure it is the only path to the tools — NetworkPolicy/security groups, service-mesh authorisation, IAM conditions, DNS egress controls, and tool-side allowlists. Without those, the gateway is a suggestion.

The PDP should be an embedded policy engine — Open Policy Agent (Rego), Cedar, or Cerbos — co-located with the gateway for low-latency, local verdicts. Adopt. The verdict is fast when policy and context are in-process. For simpler deployments, a mature agent framework’s built-in decision layer can serve, but the moment your policy needs versioning, signing, and independent audit, a dedicated engine earns its place. Whatever you choose, the policy is data the engine evaluates — not code you fork the proxy to change.

Policy lifecycle. Because the policy is the control, it needs the lifecycle discipline of safety-critical code, not the looseness of a config file. In a regulated environment that means: unit tests for every rule; replay tests that run a candidate policy against a corpus of historical decisions to see what verdicts change; shadow evaluation in production — the new policy decides alongside the live one and its verdicts are logged but not enforced — before it is promoted to enforcing; signed bundle promotion (cosign-signed, attested, staged region by region); policy diff approval as a change-managed event with a named approver; and a tested emergency rollback to the last good signed bundle. A policy change that ships without replay and shadow is how a perimeter quietly starts refusing legitimate traffic — or worse, stops refusing illegitimate traffic — in production.

The PIP state stores are where budgets, grants, and the token cache are stored. Build — this is genuinely your domain logic. A practical split is Redis for the high-velocity counters (value and velocity windows) and Postgres for the durable, ledgered records (grant registry, audited budgets).

Identity and trust are two distinct mechanisms. Adopt. Use SPIFFE/SPIRE for the agent’s own workload identity — who the calling workload is, and OAuth 2.0 token exchange / on-behalf-of tokens for the principal the agent is acting on behalf of. These answer different questions, and the audit needs both. Keep this strictly separate from secret delivery: Vault (or a secrets manager) issues external secrets and credentials; it is not your service identity system.

The escalation engine is a durable execution platform — Temporal, Restate, or Step Functions. Buy. This is what holds an escalation’s state while a human takes their time, and resumes it correctly after a deployment, a crash, or a region failover. Reserve durable execution for high-stakes escalations where the wait is genuinely open-ended; for low-stakes cases where a human can answer in seconds, a synchronous block is simpler and cheaper. Do not reach for a workflow engine for every escalation — only for those that must survive over time.

The audit fabric follows S1.1’s three-layer immutability model: a hash chain (each record carries the prior record’s hash), periodic Merkle anchoring (a single root commits to a batch), and an external witness that publishes the root outside your own infrastructure. Build on managed pair cloud immutable storage (object-lock/WORM) with a verifiable-log implementation (Sigstore Rekor is the pragmatic default) and an independent timestamp (OpenTimestamps). Own the anchoring and verification logic, because that is the part that makes your tamper-evidence claim real. And keep the audit sink separate from OpenTelemetry: OTel is your instrumentation and correlation layer; audit-grade records (decisions that move money, change records, or trigger downstream actions) route to the immutable sink, sharing only a correlation ID. A failed durable acceptance must result in the action being closed — no fire-and-forget. Note the precision: it is durable acceptance at the local regional sink that gates the action, not global anchoring, which can lag without blocking anything.

The tool layer exposes MCP servers (discoverable, scoped, granted per session) alongside native APIs and systems of record, all reachable only through the gateway’s granted, shaped calls. And the enforcement is two-sided: the tools themselves should accept calls only from the gateway’s identity. An MCP server or a native API that responds to anyone who reaches it is a hole in the perimeter. SPIFFE fits here well — the gateway can present a verifiable workload identity (an SVID, usable for mutual TLS), and the tool can authorise based on that identity, so even an agent that found a network path to the tool would not be served. Tool-side allowlisting on the gateway identity is the backstop that makes the egress controls above belt-and-braces rather than a single point.

Agent framework vs Workflow engine

An agent framework, such as LangGraph, orchestrates the agent’s reasoning and can checkpoint its graph. A workflow engine such as Temporal, Restate, or Step Functions guarantees durable, resumable execution in the event of failures. These are different guarantees, and they are routinely confused. Use the framework for agent logic. Use the engine for any escalation that a human may take minutes or hours to answer. A framework’s checkpoint is not a durability guarantee for a multi-hour human-in-the-loop hold, and betting your escalation correctness on it is a quiet way to lose actions in a restart.

What you control versus what you buy

The blunt version of this view is that there are exactly four components you should control directly — the gateway, the PDP, identity, and audit. These are where your perimeter’s correctness and your regulatory defensibility live. Control here means own the configuration, policy, trust model, and evidence posture — not necessarily build the engine from scratch; you can adopt OPA and still own every policy it runs. Almost everything else — durable execution, secret management, the immutable-storage substrate, the tools themselves — can and should be bought.

View 4 — Implementation

The first three views describe the architecture. This one makes it concrete enough to build against: the two sequences that carry most of the runtime behaviour, a policy you could load into a PDP, and the two schemas that turn “tamper-evident audit” and “approval with teeth” from adjectives into artefacts.

Sequence: the authorisation decision lifecycle

Three things in this sequence are not negotiable. First, the decision record’s durable acceptance is on the synchronous path — on ALLOW, the gateway writes the signed decision record and proceeds only on acknowledgement from the local durable regional sink; no durable acceptance, fail closed. Global anchoring can lag; local durable acceptance cannot. This is S1.1’s “backpressure fails closed” applied to the gateway: an action without a record is the most legally damaging outcome possible, so the record comes first. Second, the gateway signs at its own source, with its workload identity — it signs the authorisation decision it made; it never signs the agent’s inference record on the agent’s behalf, because a downstream component signing for an upstream one is exactly the edge-signing anti-pattern that S1.1 warns against. Third, escalation is durable — the hold sits in a durable-execution workflow, not a blocked thread, so it survives the minutes or hours a human may take and the deployments that happen in between.

Sequence: MCP tool discovery and scoped invocation

One key feature is that tool discovery is mediated. The raw upstream MCP catalogue never reaches the agent: the gateway acts as a mediated MCP client/proxy — it lists tools upstream via tools/list, filters them through the PDP against the grants held for this principal, exposes only the granted subset downstream, and executes via tools/call. An agent cannot be tempted to call — or be injected into calling — a tool it was never shown. If a granted tool is missing from the catalogue, or an ungranted one appears, that discrepancy is itself a policy event, not something to pass through. This also means the Agent frameworks tool features that allow adding local/remote tool definitions (without using MCP) should not be used. There is no mediator to control tool definitions for the agent in such cases.

Policy schema (OPA / Rego)

The PDP’s policy is data. The skeleton below shows the five primitives as Rego rules, with refuse as the default — fail-closed is the literal default value, not an afterthought.

package bounded_autonomy.authz
import rego.v1
# Failure containment (Primitive 5): nothing passes unless a rule says so.
default decision := {"verdict": "refuse", "reason": "no_matching_allow", "source": "gateway-policy"}
# Inputs assembled by the PEP from the PIPs. The PEP cryptographically verifies the
# approval token's issuer signature BEFORE the PDP runs and passes verified claims plus a
# canonical action hash.
# Capability & identity scoping (Primitive 1)
identity_valid if { input.agent_id != ""; input.principal != "" }
tool_granted if {
    some g in input.grants
    g.tool == input.tool
    input.action.category in g.scope
    time.now_ns() < g.exp_ns
}
# Action budgets — the three V's (Primitive 2). Read-time gate only; the atomic
# reserve/commit happens at the gateway (see below), never in the PDP.
within_budgets if {
    input.budgets.value.spent + input.action.value           <= input.budgets.value.cap
    input.budgets.volume.used + 1                            <= input.budgets.volume.cap
    input.budgets.velocity.window_spent + input.action.value <= input.budgets.velocity.cap
}
# Reversibility tiers (Primitive 3) — an unknown tier matches nothing and fails closed.
known_tier if input.tier in {"reversible", "bounded", "unbounded"}
# Mandatory escalation thresholds (Primitive 4) — collect ALL applicable reasons.
requires_approval if input.action.value > input.thresholds.per_action_value
requires_approval if input.action.beneficiary in data.new_beneficiaries
requires_approval if input.tier == "unbounded"
escalation_reasons contains "value_over_threshold" if input.action.value > input.thresholds.per_action_value
escalation_reasons contains "new_beneficiary"      if input.action.beneficiary in data.new_beneficiaries
escalation_reasons contains "unbounded_action"     if input.tier == "unbounded"
# Approval: action-bound + unexpired + single-use + sufficient reviewer authority.
# Signature (which authenticates the authority_class claim) is verified by the PEP;
# the PDP here checks the claimed class is *sufficient* for this action category.
valid_approval if {
    t := input.approval_token
    t.bound_action_hash == input.action_hash
    time.now_ns() < t.exp_ns
    not t.nonce in data.spent_nonces
    t.reviewer.authority_class in data.sufficient_authority[input.action.category]
}
approval_satisfied if not requires_approval
approval_satisfied if valid_approval
# ---- Verdicts: mutually exclusive; anything unmatched falls to the default refuse ----
decision := {"verdict": "allow", "source": "gateway-policy"} if {
    identity_valid
    tool_granted
    within_budgets
    known_tier
    approval_satisfied
}
decision := {"verdict": "escalate", "reasons": escalation_reasons, "source": "gateway-policy"} if {
    identity_valid
    tool_granted
    within_budgets
    known_tier
    requires_approval
    not valid_approval
}

The two verdicts can never both fire. allow requires approval_satisfied — The action either never needed approval or has a valid token. escalate requires the opposite — approval is needed, and no valid token is present yet. Anything matching neither falls through to the default refuse. So a high-value action runs escalate → approve → allow once its token arrives.

The policy never checks signatures. The PEP verifies the tokens issuer_sig before the PDP runs, then hands the PDP only verified claims and a canonical action_hash. This keeps two easily-confused questions apart. Is the reviewer who they claim to be? — The signature proves it in the PEP. Is that reviewer senior enough for this action? — the policy checks the claim authority_class against data.sufficient_authority, in the PDP. The second check is what stops a junior reviewer from approving a ₹10M transfer.

An unknown tier is refused. A tier value that the policy does not recognise matches no branch, so neither verdict fires and the default refuse applies.

Canonicalisation matters. Because the approval token binds to action_hash, that hash must be computed over a canonical representation of the action — stable field ordering, normalised formatting — or two semantically identical actions could hash differently and a valid token would fail to match (or, worse, a different action could be made to match). The PEP computes the canonical hash once, and both the token binding and the policy comparison use it.

Budget evaluation is not a pure read, and redemption is one atomic step. The within_budgets rule is a necessary gate, not a sufficient one: two concurrent actions can both pass a read-time check and jointly overspend the cap. So on allow, the gateway performs a single atomic redemption transaction — consume the approval nonce, reserve budget keyed by decision_id as an idempotency key and write the decision record as a single unit. The reservation debits the budget immediately; if the downstream action succeeds, the reservation is committed; if it fails before execution, it is released or marked as failed. The audit record links to the reservation, so the budget ledger and the evidence trail never disagree. This is the controlled write path referred to in View 1: the PDP only reads budget state during evaluation; the gateway is the only writer, and it writes atomically. The full ordering is therefore: verify signature → PDP allow → atomically (consume nonce + reserve budget + write decision record) → invoke.

A word on what “atomic” means here, because it spans up to three stores — the nonce state, the budget ledger, and the audit sink — and an architect will rightly ask where the transaction boundary is. Atomic here means logically atomic from the gateway’s perspective: approval redemption, budget reservation, and decision recording must not diverge. Implementations may realise that with a single transactional store, a write-ahead ledger, or a saga with compensating actions, the invariant matters, not the mechanism. One implementation note that follows from this: the authoritative spent-nonce state lives inside this transaction boundary, alongside the budget ledger; the data.spent_nonces the PDP reads is a read-optimised view of it, not the source of truth. Do not store authoritative nonce state in OPA data — the PDP is a reader, the redemption transaction is the writer.

Audit record schema (three linked records, per S1.1)

For an escalated action, the lifecycle produces three linked, immutable records — none of them mutated after the fact:

1. an escalate decision record, written when the gateway decides to escalate (no budget reservation yet — nothing has been authorised);
2. an allow decision record, written after the human approves, referencing the escalate record, and carrying the approval and the budget reservation (because reservation happens on allow);
3. an outcome record, written after invocation, referencing the allow record.

A non-escalated action skips record 1 and goes straight to an allow decision record and an outcome record. All store hashes and references, not raw payloads or PII; all carry the hash-chain link; the anchor block is filled at Merkle-batch time.

1 — Escalate decision record (written when the gateway escalates; no reservation):

{
  "record_type": "decision",
  "decision_id": "dec_esc_01J...",
  "prev_hash": "sha256:9f2c...",
  "ts": "2026-06-10T09:42:13.221Z",
  "producer": {
    "spiffe_id": "spiffe://corp/gateway/region-a/7",
    "signature": "ed25519:5b1e...",
    "policy_bundle": "opa-bundle@v37 (cosign:8a4f...)",
    "pdp_engine": "opa@1.4.2"
  },
  "actor": {
    "agent_workload": "spiffe://corp/agent/payments/3",
    "acting_principal_ref": "tok_obo_8a2f3c",
    "human_subject_ref": "tok_pt_91be4d"
  },
  "request": {
    "tool": "make_payment",
    "action_ref": "blob://payloads/2026/06/10/aef9...",
    "action_hash": "sha256:1c77...",
    "reversibility_tier": "bounded"
  },
  "verdict": { "value": "escalate", "source": "gateway-policy", "reasons": ["value_over_threshold", "new_beneficiary"] },
  "context_at_decision": {
    "grants_in_force": ["grant_4471"],
    "budget_state": { "value": {"spent": 18000, "cap": 50000} },
    "guardrail_evals": [ {"name": "sanctions", "result": "pass", "score": 0.0} ]
  },
  "anchor": { "merkle_batch_id": "mb_2026061009", "witness": "rekor:88123 / rfc3161:..." }
}

2 — Allow decision record (written after approval; carries approval + reservation):

{
  "record_type": "decision",
  "decision_id": "dec_alw_01J...",
  "escalation_of": "dec_esc_01J...",
  "prev_hash": "sha256:b73d...",
  "ts": "2026-06-10T09:43:58.004Z",
  "producer": { "spiffe_id": "spiffe://corp/gateway/region-a/7", "signature": "ed25519:6c0a..." },
  "request": { "tool": "make_payment", "action_hash": "sha256:1c77...", "reversibility_tier": "bounded" },
  "verdict": { "value": "allow", "source": "gateway-policy" },
  "approval": { "token_id": "apr_22f0c8", "reviewer_ref": "tok_rv_5c", "authority_class": "payments_l2", "review_dwell_ms": 41200 },
  "context_at_decision": {
    "budget_state": { "value": {"spent": 18000, "cap": 50000} },
    "budget_reservation_id": "rsv_6b20fa"
  },
  "anchor": { "merkle_batch_id": "mb_2026061010", "witness": "rekor:88126 / rfc3161:..." }
}

3 — Outcome record (written after invocation; references the allow decision):

{
  "record_type": "outcome",
  "outcome_id": "out_01J...",
  "decision_id": "dec_alw_01J...",
  "prev_hash": "sha256:c41a...",
  "ts": "2026-06-10T09:44:02.880Z",
  "producer": { "spiffe_id": "spiffe://corp/gateway/region-a/7", "signature": "ed25519:77a2..." },
  "result": "success",
  "downstream_refs": ["txn_AE99023117"],
  "tool_response_hash": "sha256:4d9e...",
  "reservation_status": "committed",
  "anchor": { "merkle_batch_id": "mb_2026061011", "witness": "rekor:88129 / rfc3161:..." }
}

Note guardrail_evals records what each control evaluated on this request (“sanctions: pass, 0.0”), not merely that it was enabled — S1.1’s point that “toxicity filter: enabled” is not auditable but “toxicity filter: pass (0.04)” is. review_dwell_ms is captured on every approval so rubber-stamp review patterns are visible in the evidence rather than hidden by it. escalation_of links the allow decision back to the escalation that triggered it; budget_reservation_id appears only on the allow record (reservation happens on allow); and reservation_status on the outcome closes the loop — committed on success, released or failed otherwise — so the ledger and the evidence never disagree. Outcome recording is itself idempotent on decision_id: a retry after a downstream timeout (where the gateway is unsure whether the tool call landed) cannot produce a duplicate or divergent outcome record. The field names acting_principal_ref (the OBO principal, the agent acts for) and human_subject_ref (the patient/customer the decision concerns) are spelt out because “principal” and “subject” are otherwise overloaded.

Approval token schema (escalation with teeth)

{
  "token_id": "apr_22f0c8",
  "issued_at_ns": 1781084635000000000,
  "exp_ns": 1781084935000000000,
  "bound_action_hash": "sha256:1c77...",
  "nonce": "n_7c41ab",
  "reviewer": { "reviewer_ref": "tok_rv_5c", "authority_class": "payments_l2", "review_dwell_ms": 41200 },
  "issuer_sig": "ed25519:c903..."
}

Short-lived (claims carry epoch-nanosecond timestamps, matching the PDP’s time.now_ns() comparison — human-readable times are reserved for audit records), bound to a specific canonical action hash, single-use via a nonce the gateway burns on redemption after the allow verdict, and signed by the human-review service — the four properties that make “a human approved this” a verifiable claim rather than a comforting one.

Threat Model — What the Perimeter Stops

The architecture is easier to defend to a security review when the threats and their controls are named explicitly rather than left implicit. The table is deliberately short — these are the threats the bounded-autonomy perimeter exists to contain, mapped to the control that contains each.

The point of writing it down is not the table itself — it is that every row has a named owner from the operating-responsibilities section, and a test in the policy lifecycle. A threat with a control but no owner and no test is a threat you have documented, not one you have contained.

Key Build / Buy Choices

Five decisions determine whether this architecture is something you can fund, staff, and defend. The first three are consequential; the last two are where teams most often take shortcuts that cost them later.

Choice 1 — Where does the enforcement boundary live?

The options: an in-process SDK the agent imports; a sidecar/service-mesh policy filter; or a reverse-proxy gateway the call must traverse.

The recommendation: the reverse-proxy gateway. It is the only option that keeps the enforcement boundary genuinely outside the agent’s reach. The SDK is the cheapest to start with and the easiest to compromise — it lives inside the process you do not trust. The sidecar is a reasonable middle ground in a mesh-native estate, but it inherits the mesh’s failure modes and identity model, whether you want them or not. The proxy costs more to operate and adds a hop of latency, and it is worth it, because it is the one design where “the agent cannot bypass the perimeter” is a property of the network rather than a promise in your code.

Choice 2 — What is the Policy Decision Point?

The options: build a bespoke policy engine; adopt a general engine (OPA/Cedar/Cerbos); or use the framework’s built-in decision layer.

The recommendation: adopt OPA or Cedar; use the framework’s built-in only for low-complexity, low-assurance cases. Building your own policy engine is almost always a mistake — you will spend two years rebuilding what OPA already does, minus the ecosystem, the tooling, and the auditor familiarity. The framework’s built-in layer is fine when the policy consists of a handful of static rules, but it rarely supports the versioning, signing, and independent auditability that a regulator will ask for. Adopt the engine; spend your build budget on the policies, which are your actual domain knowledge.

Choice 3 — How are escalations handled?

The options are: a synchronous block that holds the request open; a queue that the human pulls from; or a durable execution engine that suspends and resumes the workflow.

The recommendation: durable execution for high-stakes, synchronous block for low-stakes. Match the mechanism to the wait. A low-stakes escalation that a human can clear in seconds does not require Temporal; a synchronous hold is simpler and has fewer moving parts. A high-stakes escalation that may wait hours, span a deployment, or survive a crash must be durable — anything less risks dropping an in-flight action when the process recycles. Drawing this line by stakes (and therefore by expected wait time) keeps you from paying durable-execution complexity on every trivial approval.

Choice 4 — How is identity propagated?

The options: build a bespoke token-passing scheme, or adopt SPIFFE/SPIRE for workload identity and OAuth 2.0 token exchange / on-behalf-of for the principal.

The recommendation: adopt, and keep workload identity separate from secret delivery. Rolling your own identity propagation is a reliable way to end up with anonymous agent actions and an audit that cannot answer “on whose behalf?”. Adopt the standards, and resist the temptation to fold service identity into your secrets manager — they are different concerns, and merging them produces a system where you can no longer cleanly attribute an action after a credential rotation.

Choice 5 — What is the posture of the audit fabric?

The options: build an append-only store from scratch; buy a managed audit/SIEM product; or build on managed primitives.

The recommendation: build on managed. Use the cloud’s immutable storage (object lock/WORM) and a managed transparency log or ledger service for durability, and own the anchoring and verification logic yourself. A pure buy rarely gives you the action-level, decision-source-tagged record this architecture needs; a pure build wastes effort reinventing durable storage. The middle path gives you a tamper-evident record you can actually stand behind in an audit.

The roll-up

The pattern in the postures is the message: control the four components where correctness and defensibility live; buy or adopt everything else. A team that tries to build all eight will not ship; a team that buys all eight will not be able to answer the regulator.

What This Architecture Does Not Solve

The architecture is strong, but it is not magic, and overstating it is its own risk. Bounded autonomy contains a blast radius; it does not guarantee correctness. A perfectly bounded agent can still make a legitimate-but-wrong decision within its authority, burn a session budget in an unhelpful loop, generate alert fatigue through over-tuned thresholds, or confidently call the wrong granted tool. The architecture limits the consequence of each of these; it does not prevent the mistake.

That is the right division of labour. Correctness is a model-and-agent problem. Containment is an architecture problem. Both matter, and conflating them is how you end up either trusting a model you should not or strangling an agent that could safely do far more. Brakes do not make a car go the right way. They make it safe enough to go fast.

Prompts can guide behaviour. Architecture must enforce authority.

The teams that build the perimeter first — before the agent goes into production, before the demo, before the headline — are the teams whose agents are still running a year later.