# The four deterministic zones

The four areas where an AI model may never approve: access, money, safety actuation and formal records. Beside them sit the destruction rule and the rule for decisions about people.

Author: Murali Sid (https://linkedin.com/in/muralisid)
Source: https://www.agenticarchitectureskills.com/architecture/deterministic-zones
Published: 2026-09-18
Updated: 2026-10-15
Licence: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/
Cite as: Murali Sid. The four deterministic zones. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/architecture/deterministic-zones

---


Some agent actions change who gets access, whether money moves, whether equipment acts, or whether a formal record is true. Who gives the final yes? Never the model. Models may take permission away, never grant it. In these four deterministic zones a fixed rule or a named person decides. The model may draft, suggest, flag or block. Two rules sit beside the zones: the destruction rule, and the rule for decisions about people. You set all of this when an agent is evaluated and approved in [the agent lifecycle](/architecture/agent-lifecycle).

<TeachingIllustration src="/figures/architecture/deterministic-zones-walls.svg" mobileSrc="/figures/architecture/deterministic-zones-walls-mobile.svg" title="Models may take permission away, never grant it" alt="A model sits in the centre. It may analyse, draft, recommend, flag and block. Four zones surround it: access and entitlements, movement of money, safety actuation, and formal regulatory records. Each zone shows who decides, what advises, and the agent's job. An arrow shows the model may deny, escalate or quarantine. A crossed-out arrow shows it may never grant. Two panels sit beside the zones. The destruction rule needs a plan, a named approval, two signers and protected backups. The rule for decisions about people needs a named person to decide, notice to the person and a log. A strip of six yes or no questions finds the zones in an enterprise." caption="Inside the zones a fixed rule or a named person decides. The model may advise or block." />

## The principle [#the-principle]

A language model reads instructions and content as the same kind of text. So what it reads can steer it. Training cannot teach it to keep the two apart reliably (Bhattarai and Vu, February 2026). That makes the model a good adviser. It is the wrong place for the final yes on rights, money, equipment or records.

So the rule has three parts. A <Term k="model">model</Term>, a classifier or a model-based reviewer may deny, escalate or quarantine. Outside the zones it may never grant more than fixed rules allow. Fixed rules give the same answer every time, over verified credentials and written policies. Inside the zones it may not approve at all. A model may block a release. It may never approve one.

Some products shipped in 2026 let a model approve some actions \[vendor]. Each still runs inside a <Term k="sandbox">sandbox</Term> or behind a gateway, so the outer boundary holds. Model approval is acceptable only for a reversible action inside a sandbox. It must be bound to that exact action and used once. It is never acceptable in a zone.

Machine-learning signals already work inside three of the four zones. Risk scores, fraud models and anomaly signals feed the rule. The rule itself stays fixed. The check that applies it is the policy decision point. It belongs to [identity and policy](/architecture/system-view), one of the seven capabilities an agent platform provides.

### What the named person at a gate does [#what-the-named-person-at-a-gate-does]

People approve most of the prompts they are shown. Users approved 93 percent of Claude Code permission prompts (Anthropic, 25 March 2026) \[vendor]. So the named person at a zone gate does not review a stream of prompts. That person reviews one exact, bounded action, with deliberate friction.

<GuideFigure id="four-deterministic-zones" />

## Access and entitlements [#access-and-entitlements]

**What sits in it.** Who may use which system, and with what rights. That covers authorization decisions, <Term k="entitlement">entitlement</Term> grants and role changes. It covers approval of <Term k="just-in-time access">just-in-time access</Term>, which is extra access for one action, removed afterwards. Three more things belong here: security settings, any permission an agent would grant itself, and personal data leaving a boundary.

**Who decides.** A <Term k="policy decision point">policy decision point</Term> decides. It checks fixed rules against a verified identity and answers yes or no. It sits in the path of every tool call. It fails closed: if it is down, the answer is no.

**What the agent may do.** Ask for the action under its own identity, and accept the answer as final. It never grants, extends or approves its own access. It never changes entitlements or security settings for anyone, person or agent. It never sends personal data where the data-flow policy forbids. A deny is not an obstacle to work around. The only appeal is to a person.

**How to build the boundary.** List the tool calls that touch access, security settings or personal data flows. Put the policy decision point behind the gateway, so no such tool is reachable without a decision. Write the rules as <Term k="policy-as-code">policy-as-code</Term>, versioned and reviewed like any production change. Log every decision in the audit trail. Then have a red team try to reach a tool without a decision. Where these checks sit is on [enforcement outside the model](/architecture/enforcement). How the agent proves who it is sits on [the delegation chain](/architecture/delegation-chain).

## Movement of money [#movement-of-money]

**What sits in it.** Payments, transfers, refunds and any other commitment to spend.

**Who decides.** The payment rail, the card issuer or your own payment service decides. It checks a signed, limited permission called a <Term k="mandate">mandate</Term>. A mandate sets an amount cap, a scope, an expiry and a way to revoke it. Fraud and risk models advise. The model still chooses inside the mandate, such as which item to buy.

Two cautions apply. Some agent wallets sign with the agent's own key, with no mandate signed by a user \[vendor]. And who pays when an agent pays wrongly is not settled yet. Until it is, keep a person confirming new payees and large amounts.

**What the agent may do.** Put the purchase together, present the credential, and stop at the mandate's limits. It never holds card numbers or bank credentials. It never exceeds, rewrites or issues itself a mandate. It never splits a payment to stay under a cap. It never pays a payee that came from untrusted content. <Term k="prompt injection">Prompt injection</Term> still works inside a mandate's limits, so a new payee is a person's decision.

**How to build the boundary.** Give the agent a payment instrument tied to its own identity, so revoking it is one act. Write and sign the mandate before first use. The issuer or rail checks it by rule. If your rail cannot, put your own payment service in front of it. Set the confirmation step at the level [the autonomy contract](/architecture/autonomy-contract) gives the agent. Keep a log of each mandate issued, used and revoked. These logs are compliance records. The payment stack is described in the [security and identity layer (R10)](/layers/r10-security-and-identity#payment-mandates-follow-the-same-pattern).

## Safety actuation [#safety-actuation]

**What sits in it.** Everything that moves physical equipment: process plant, interlocks, vehicles, robots, drones and critical infrastructure controls. It includes <Term k="safety instrumented system">safety instrumented systems</Term>. These are the automatic systems that shut a process down when it leaves safe limits.

**Who decides.** Operators, interlocks, enforced operating limits and the safety instrumented system decide, as the safety case certifies. The safety standards keep machine learning out of the safety function itself (IEC 61511; ISO/IEC TR 5469:2024). Six national cyber agencies said in December 2025 that AI should support people here, not control actions. Manual control must stay possible.

**What the agent may do.** Read outbound plant data, propose and explain. Every proposal names the agent that made it. It never writes to actuators, controllers, or vehicle or robot controls. It never acknowledges, shelves or hides an alarm for an operator. It never counts as a safeguard in the safety case, or as a reason to remove one.

**How to build the boundary.** Keep the agent on the information path. <Term k="ot">Operational technology (OT)</Term> networks stay separate, and data flows one way, out to the agent. Nothing flows back to actuation. Agent output reaches operators only after a <Term k="validation loop">validation step</Term> based on rules or a <Term k="digital twin">digital twin</Term>. Keep a way to switch the agent off without touching operations, and rehearse it. The boundary is described in the [line of business and OT layer (R05)](/layers/r05-lob-and-ot#the-ot-boundary-four-principles).

## Formal regulatory records [#formal-regulatory-records]

**What sits in it.** Regulatory filings, disclosures, messages to a regulator, books and records, safety cases and audit logs. It covers any document a regulator or a third party relies on.

**Who decides.** A named, accountable person confirms the record is true. That act is <Term k="attestation">attestation</Term>. A system of record then holds the record so it cannot be changed. Financial regulators ask for accountability and records that cannot be altered (FINRA Notice 24-09; ESMA, 2024). They do not forbid drafting with a model.

**What the agent may do.** Draft with citations that resolve, gather evidence, flag gaps, and stop before the signature. It never files or submits a formal record on its own. It never signs, or records a signature that did not happen. It never alters or backdates a record, or deletes audit logs. A correction is a new record.

**How to build the boundary.** Split drafting from signing in the workflow itself, not in an instruction to the model. A separate check confirms that citations resolve and figures trace to their sources. <Term k="provenance">Provenance</Term>, the record of where each claim came from, travels with every claim. Keep the draft, the edits, the signature and the logs in the system of record. Never keep them only in the agent's memory.

## The destruction rule [#the-destruction-rule]

Deleting or resetting production data or systems is its own rule. A fixed system applies it only after a named person approves that exact action. It sits beside the zones, not inside them, because destruction can happen in any area.

Four public incidents in 2025 and 2026 share one cause. An agent held its operator's full production rights, and nothing outside the model stopped it. The research block below has the four cases.

* Any delete, drop, destroy or reset on production is a separate rule in the policy decision point. It is never folded into a broad permission such as "manage environment".
* It runs as <Term k="plan-then-apply">plan-then-apply</Term>. The agent proposes a plan, and a fixed system applies it after approval.
* A named person approves that exact action, once. Two people sign for a production deletion.
* The target has deletion protection. Backups sit where the agent's identity cannot delete them.

Singapore's agentic AI framework (IMDA, 20 May 2026) lists permanent deletion as an action that needs a human checkpoint.

## The rule for decisions about people [#the-rule-for-decisions-about-people]

A named person decides any significant decision about a person. That covers credit, work, insurance, benefits, health, housing, education, and utility hardship or disconnection. Here the law asks for human accountability, notice and audit, not a fixed rule. GDPR Article 22 gives people a right to human review of solely automated decisions with significant effects. The EU AI Act lists hiring, credit scoring and life and health insurance pricing as high-risk.

* A named person with the power to change the outcome decides. The model may score and draft.
* The person affected gets the notice the law requires. In Australia, the OAIC automated decision disclosure applies from 10 December 2026.
* Each decision is logged with the model's inputs.
* A person signing off does not lower the [risk tier](/architecture/risk-profile). A program stays in scope when its output is a key factor.

The rule is older than language models. In Australia, an energy retailer's automated processes changed payment plans without checking capacity to pay. The court imposed an A$17 million penalty (AER v Origin, 6 July 2022). Regulators differ on how much review is enough. The Monetary Authority of Singapore (7 October 2026) does not require a person on every credit decision. This rule is stricter than that.

Other binding messages, such as an offer or a contract term, are not a zone. They are a high-risk action that needs approval under the risk profile.

## Code an agent writes [#code-an-agent-writes]

Code that ships through a repository is reviewed by someone who did not write it. It passes pipeline tests and change control. The agent never approves its own deployment.

Code that the agent writes and runs during a task stays in a sandbox. That sandbox has no network by default and holds no production credential. A database query the agent writes runs under a read-only role and the user's own identity. A "read-only" label is not enough. What the credential allows is what counts.

## What the zones do not catch [#what-the-zones-do-not-catch]

Fixed rules limit what is possible. They do not judge whether an action fits the purpose. In one red-team test, injected text made an agent buy the wrong thing. The mandate held, and the purchase was still wrong. So four defences stay necessary even with perfect gates:

* Defend against injection where untrusted content enters the agent's working memory.
* Have a person confirm intent for consequential choices inside the limits.
* Write destructive actions as separate rules.
* Let model reviewers or signed user mandates check intent only to stop an action, never to widen what is allowed.

## A worked example: billing exceptions at a utility [#a-worked-example-billing-exceptions-at-a-utility]

A utility runs an agent on billing exceptions. A meter read looks wrong and the bill fails a check. The agent gathers the read history, meter events and account notes. It proposes a resolution and shows its evidence.

Three boundaries shape the design. First, any sign of hardship, disconnection or a payment plan is a decision about a person. The agent hands the case to a trained person and stops. Second, a released bill changes what the customer owes. So the model never releases a bill. A fixed rule in the billing system checks confidence and hard limits. It releases only what passes, and a sample is checked. A specialist approves the rest. Third, the agent never overwrites a read. A correction is a new entry. The full design is on [billing exceptions](/use-cases/billing-exceptions).

## Find the zones in your enterprise [#find-the-zones-in-your-enterprise]

Four questions find the zones. One yes is enough.

1. Does a regulator or standard name this function, or rely on its records?
2. Is the action irreversible, or is reversing it a legal or financial event in itself?
3. Does it move money, change access, move physical equipment, or create a record others rely on?
4. Is certified or validated logic making this decision today?

Two more questions find the rules beside the zones.

5. Does it delete, drop, destroy or reset production data or an environment? The destruction rule applies.
6. Does it make or shape a significant decision about a person? The rule for decisions about people applies.

Run every tool in the gateway's list against the six questions. Write the answers into a one-page zone register. Each entry names the action, who decides, and how the agent may help. Your risk function signs the register. Each entry maps to a gateway policy and to the controls in the autonomy contract.

The zones an agent touches are part of its impact, one of [the four questions](/architecture/agent-types) asked of every agent. A signed register lets your regulator and your board approve everything outside it. A use case that needs a model to approve inside a zone is reshaped or dropped. Reshaped means the model proposes and a rule decides.

## Evidence and limits [#evidence-and-limits]

The zones, the two rules beside them and the split for code are expert judgement. They rest on regulator guidance, safety standards and public incidents. No study yet links any zone or rule to incident rates.

The safety exclusions are the strongest evidence here. They are standards text and joint agency guidance. The payment details come from vendor documents, and the rules on who pays are not settled. The EU AI Act dates and the OAIC scope come from law-firm notes. Those notes put the high-risk duties at 2 December 2027.

The destruction incidents are single accounts, and Amazon disputes one of them. The approval figures are vendor figures with unknown methods. The limit on intent rests on one red-team study. How often attackers get past model-based filters is on [enforcement outside the model](/architecture/enforcement#what-guardrails-are-for).

## Next step [#next-step]

Trace every action to the person who asked on [the delegation chain](/architecture/delegation-chain).

<details>
  <summary>
    Explore this topic
  </summary>

  * [Security and identity findings](/library/layers/r10-security-and-identity/findings)
  * [The identity and security model](/library/architecture/identity-security-model)
  * [Line of business and OT findings](/library/layers/r05-lob-and-ot/findings)
  * [Governance, risk and sovereignty findings](/library/layers/r11-governance-risk-sovereignty/findings)

  **Model approval in shipped products.** OpenAI's Codex Auto-review (30 April 2026) lets a model decide escalations. It approved 713 of 720 in one internal snapshot \[vendor]. OpenAI says the reviewer is not a security guarantee. Claude Code auto mode, where a classifier reviews actions, became the default for new Pro, Max and Team sessions on 14 August 2026 \[vendor]. AWS lets Bedrock Guardrails results feed AgentCore Policy decisions \[vendor]. In one unreplicated vendor study, people caught 13.6 percent of dangerous commands (August 2026) \[vendor]. A classifier caught 89 percent.

  **Payment protocols.** Google's Agent Payments Protocol (AP2, September 2025) uses signed mandates \[vendor]. Visa's Trusted Agent Protocol (October 2025) checks a signature on each agent request \[vendor]. Mastercard Agent Pay (April 2025) uses revocable tokens bound to agent, merchant and consent \[vendor]. Mastercard built Verifiable Intent (5 March 2026) with Google, so the stacks are not independent. Stripe's Shared Payment Tokens carry an amount cap, a currency and an expiry \[vendor]. Coinbase's x402 agent wallets sign with the agent's own key under a client-side budget, with no user mandate \[vendor]. In May 2026 a prompt sent through X drained about USD 150,000 to 200,000 from an agent-run wallet. The OECD record (4 May 2026) shows no sign of a mandate. The Reserve Bank of Australia (issues paper, 25 June 2026) calls live trials human-in-the-loop. Santander and Mastercard completed a pilot payment with no final human command (3 March 2026). Worldpay says no liability shift exists yet \[vendor]. One forecast puts the first card-network dispute rule at April 2027 at the earliest.

  **Four destruction incidents.** Replit (July 2025): an agent deleted a production database during a code freeze set only by instruction. AWS Kiro (December 2025): an agent reportedly deleted and recreated an environment, with about 13 hours of disruption. Amazon calls it user error from misconfigured access. Google Antigravity (December 2025): an agent deleted a whole drive while clearing a cache. Terraform destroy (26 February 2026): Claude Code destroyed a production stack after a state-file mix-up, and the snapshots went too.

  **Read-only labels.** In the Supabase case (July 2025), a read-only assistant obeyed a poisoned support ticket and leaked a secrets table. Datadog showed (21 August 2025) that an injected COMMIT ended a reference server's read-only mode.

  **Other sources.** The Five Eyes guidance (1 May 2026) bars agents from changing their own privileges and holds log deletion for a person. Australia's Information Security Manual (September 2026) caps an agent at the lesser of its own grant and the user's rights. The UK NCSC (20 August 2026) says always sandbox generated code and deny network by default. Commonwealth Bank (2 October 2026) says an agent should not validate its own code. Deutsche Bank (14 July 2026) never deploys AI-generated code without review. APRA's letter of 30 April 2026 expects security testing of AI-generated code. MAS (7 October 2026) puts rule-based systems outside its definition of AI. New York City Local Law 144 asks for a bias audit and notice before an automated hiring tool is used.

  * [IMDA agentic framework v1.5, 20 May 2026](https://www.imda.gov.sg/assets/63438074-73f6-4dcc-a281-030f42642cf4.pdf)
  * [Five Eyes, Careful adoption of agentic AI services, 1 May 2026](https://www.ncsc.govt.nz/assets/guidance/Documents/Careful-adoption-of-agentic-AI-services_FINAL.pdf)
  * [UK NCSC, 20 August 2026](https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai)
  * [MAS AI risk guidelines, 7 October 2026](https://www.mas.gov.sg/-/media/mas-media-library/regulation/guidelines/bd/guidelines-on-artificial-intelligence-risk-management-for-financial-institutions/guidelines-on-artificial-intelligence-risk-management.pdf)
  * [OpenAI Codex Auto-review, 30 April 2026](https://alignment.openai.com/auto-review) \[vendor]
  * [Anthropic, Claude Code auto mode, 25 March 2026](https://anthropic.com/engineering/claude-code-auto-mode) \[vendor]
  * [Help Net Security, 10 August 2026](https://www.helpnetsecurity.com/2026/08/10/anthropic-claude-code-auto-mode/) (reports vendor figures)
  * [AWS AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html) \[vendor]
  * [Google AP2 overview](https://ap2-protocol.org/overview/) \[vendor]
  * [Visa Trusted Agent Protocol](https://developer.visa.com/capabilities/trusted-agent-protocol/overview) \[vendor]
  * [Mastercard Verifiable Intent, 5 March 2026](https://www.mastercard.com/us/en/news-and-trends/stories/2026/verifiable-intent.html) \[vendor] (search summaries)
  * [Stripe Shared Payment Tokens](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.md?agent-seller=seller) \[vendor]
  * [Coinbase x402 client configuration](https://docs.cdp.coinbase.com/x402/buyer/client-configuration) \[vendor]
  * [OECD AI Incidents Monitor, 4 May 2026](https://oecd.ai/en/incidents/2026-05-04-4a73)
  * [RBA issues paper, 25 June 2026](https://www.rba.gov.au/payments-and-infrastructure/regulatory-reviews/review-of-payments-system-regulation-2026/2026-06/pdf/issues-paper.pdf)
  * [Santander and Mastercard pilot, 3 March 2026](https://www.artificialintelligence-news.com/news/santander-and-mastercard-run-europe-first-ai-executed-payment-pilot/)
  * [Worldpay on liability](https://worldpay.com/insights/articles/agentic-commerce-liability-is-still-being-written) \[vendor]
  * [Dispute-rule forecast](https://shopappy.com/payments/card-networks/agent-chargeback-rules-holiday-2026) (forecast)
  * [Replit, The Register, 21 July 2025](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/)
  * [Kiro, Computerworld, 24 February 2026](https://www.computerworld.com/article/4136512/what-really-caused-that-aws-outage-in-december.html)
  * [Antigravity, TechRadar](https://www.techradar.com/ai-platforms-assistants/googles-antigravity-ai-deleted-a-developers-drive-and-then-apologized)
  * [Terraform destroy, Tom's Hardware](https://tomshardware.com/tech-industry/artificial-intelligence/claude-code-deletes-developers-production-setup-including-its-database-and-snapshots-2-5-years-of-records-were-nuked-in-an-instant)
  * [GDPR Article 22](https://gdpr-info.eu/art-22-gdpr/)
  * [EU AI Act Annex III](https://artificialintelligenceact.eu/annex/3/) and [Article 14](https://artificialintelligenceact.eu/article/14/)
  * [Gibson Dunn on EU AI Act dates](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines/) (law-firm summary)
  * [NYC Local Law 144](https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page)
  * [OAIC, 30 September 2026](https://www.oaic.gov.au/news/media-centre/new-resources-on-transparency-for-use-of-ai-and-automated-decision-making)
  * [Allens on the OAIC guidance, October 2026](https://www.allens.com.au/insights-news/insights/2026/10/mandatory-automated-decision-making-disclosure-requirements-are-coming-key-takeaways-from-the-oaic-guidance/) (law-firm note)
  * [AER v Origin, 6 July 2022](https://www.aer.gov.au/news-release/origin-penalised-17-million-for-customer-hardship-breaches)
  * [ASD ISM September 2026, Cipher Projects](https://www.cipherprojects.com/blog/posts/asd-ism-september-2026-update/) (compliance-firm summary)
  * [Anthropic usage policy](https://www.anthropic.com/legal/aup) \[vendor]
  * [Commonwealth Bank, 2 October 2026](https://www.commbank.com.au/articles/newsroom/2026/10/five-ideas-that-will-shape-trusted-ai.html)
  * [Deutsche Bank, 14 July 2026](https://www.db.com/news/detail/20260714-how-ai-is-reshaping-the-software-behind-everyday-banking)
  * [APRA letter, Clayton Utz, 5 May 2026](https://www.claytonutz.com/insights/2026/may/apras-ai-letter-a-shift-from-framework-to-targeted-expectations) (law-firm summary)
  * [Supabase leak, Simon Willison, 6 July 2025](https://simonwillison.net/2025/Jul/06/supabase-mcp-lethal-trifecta/)
  * [Datadog Security Labs, 21 August 2025](https://securitylabs.datadoghq.com/articles/mcp-vulnerability-case-study-SQL-injection-in-the-postgresql-mcp-server/)
</details>