Skip to main content
Agentic Architecture Skills.
Start hereUse casesArchitectureIntelligence ladderKnowledge & memoryResearchSkills
Architecture

Enforcement outside the model

A rule written in a prompt is a request. The same rule checked by a separate system is a control. Three places enforce outside the model: the gateway, the policy decision point, and fixed rules promoted from what the agent learned.

By Murali SidLinkedInPublished Updated

A rule written in a prompt is a request. The model may follow it, or a crafted document may talk it out of it. The same rule, checked by a separate system the model cannot argue with, is a control. So the rules that bind an agent are enforced outside the model, in three places. The first is the gateway that every tool call passes through. The second is the policy decision point, which says yes or no to each consequential action. The third is a set of fixed rules promoted from what the agent learned, after testing and approval. Two of the seven capabilities an agent platform provides do this work: the tool gateway, and identity and policy.

A tool call passes from the agent through the gateway, which is enforcement point 1. It then passes the policy decision point, enforcement point 2, and reaches the tool. Enforcement point 3 is a learned rule. It lands as policy-as-code only after tests and human approval. A ring shows the ten guardrail categories, marked D for deterministic, M for model-based and H for hybrid. Seven are deterministic. Input, output and monitoring also use model checks. A strip shows what Tier 1 (basic), Tier 2 (enhanced) and Tier 3 (strict) add. It also shows what the agent can do that switches categories on.
Enforcement points and guardrailsThe three enforcement points are places on the path, not risk tiers. A model-based check may warn or block. It never stands alone between an agent and an irreversible effect.Open image at full size ↗

What a model can be talked into

A model reads its instructions and the content it works on as one stream of text. Training alone cannot teach it to keep the two apart. So text inside an email, a web page or a ticket can steer it. EchoLeak showed this in 2025. A crafted email made a retrieval agent send company data out, with no click from the user. It scored 9.3 out of 10 on the standard severity scale (CVE-2025-32711). So the checks that matter sit outside the model.

Enforcement point 1: the gateway

Every tool call passes through the tool gateway. It is the single door between agents and the systems they touch. It keeps a list of allowed tools and checks that no tool's description has changed. It swaps in the identity of the person who asked, using token exchange. It adds credentials at the last moment, so the agent never holds secrets. It limits how often each tool is called, and it records every call.

Approval rules may be written in the harness, the engineering shell around the model. Only the harness sees the whole task. But the rules are enforced at the gateway, because the gateway cannot be talked out of them. The gateway is built in the integration fabric layer (R03).

Enforcement point 2: the policy decision point

The policy decision point sits in the path of every tool call. It checks fixed rules against who is asking and what they want to do. Then it says yes or no. It checks every consequential action, and it fails closed: if it is down, the answer is no.

Two kinds of rules engine are common. Cedar-style engines answer in under a millisecond, and their logic is formally verified. They hold no state between calls. Open Policy Agent style engines handle rules that join data from several sources.

Speed matters here. A policy engine answers in a millisecond or a few. A guardrail that calls a large language model takes about 1.5 seconds. That is about a thousand times slower, on every action, for as long as the agent runs.

Two newer checks can sit beside it. The first tracks data from untrusted sources and blocks any flow the policy forbids. One such tool, FIDES, stopped every policy-breaking injection on a standard test set [vendor]. Its own documentation still calls it experimental (October 2026). The second verifies outputs with formal logic. AWS Automated Reasoning checks have been generally available since August 2025 [vendor].

Enforcement point 3: promoted rules, landed outside the model

An agent can learn a rule from its own work. That rule counts only after it passes the learning flywheel. It must survive counterexamples, which are test cases built from real failures. It must not make any existing eval worse. A person must approve it. Then it is written as policy-as-code, versioned and deployed apart from the model. A rule the model only reads is still a request.

This has a ceiling. One study read real agent instruction files statement by statement. About a quarter of the statements could be checked by a fixed rule as written. The other 74 percent depended on context nobody can define in advance. That is why the gateway and the policy decision point carry most of the load.

What guardrails are for

A guardrail is a filter, often a model itself, that screens what goes into or comes out of an agent. Guardrails are an early warning. They are never the lock. Attackers get past them often, and attacks tuned to a defence get past more. Guardrails still help with content policy, spotting personal data, and monitoring, where a miss can be tolerated.

Watch a guardrail's block rate in both directions. A spike suggests an attack. A drop suggests a broken setting. The measured bypass rates are in Evidence and limits below.

The ten guardrail categories

No single industry list of guardrails exists. But the 2026 guidance from regulators and security agencies shares one shape. Bound the agent by design. Enforce approval and limits outside the model. Isolate where code runs. Monitor, and keep a stop switch. This guide groups the controls they name into ten categories. Seven are fixed rules. Input, output and monitoring also use model checks.

  1. Input. Treat outside content as untrusted. Keep instructions apart from data. Use typed formats between agents. Injection classifiers add a model check.
  2. Output. Mask known patterns, such as card numbers. Use data loss prevention. Check that answers are grounded and citations resolve. An output takes the highest data class of its inputs. Validate before display. Grounding checks use a model.
  3. Tool and action. Allow only listed tools, with pinned versions. Use strict input formats. Put a policy decision point on each call, failing closed. Write destructive actions as separate rules. Keep reading and acting roles apart.
  4. Identity and access. Give each agent its own identity. Use short-lived, scoped credentials. Use just-in-time access for high-impact actions. The agent gets the lesser of its own rights and the user's. It never grants itself access. A proxy injects credentials.
  5. Data and egress. Deny network access by default. Allowlists name operations, not just domains. An outbound proxy checks identity. Public-facing agents stay away from internal data. Data is routed by its class.
  6. Spend and rate. Set caps per run and per agent. Limit rates and retries. Add circuit breakers at agent, workflow and business-unit level. Cap payment mandates.
  7. Runtime isolation. Run any code in a sandbox. Untrusted code that touches sensitive data gets stronger, hypervisor-level isolation. Allow no network by default and no production credentials.
  8. Monitoring and kill switch. Keep logs the agent cannot change. Add anomaly detection and watcher agents, which use models. Place a kill switch in identity, gateway, runtime and harness. Keep a way back to manual operation.
  9. Change control. Version and approve prompts, tools, policies, models and memory rules. Red-team after a major change. A listed change re-runs the tests.
  10. Human oversight. Designers, not the agent, set checkpoints for high-stakes, irreversible and unusual actions. Approval is bound to the exact action. If the approval system fails, the answer is no. One approval covers one bounded action. The deterministic zones, the destruction rule and the rule for decisions about people sit here.

A model-based check may warn or take permission away. It never stands alone between an agent and an irreversible effect.

Which categories apply at each risk tier

How much of each category an agent needs depends on its risk tier, set on the risk profile. The tier is fixed when the agent is approved in the agent lifecycle. There are three tiers: Tier 1 (basic), Tier 2 (enhanced) and Tier 3 (strict). Each keeps everything in the tier below and adds to it. What the agent can do also switches categories on. The last column names those triggers.

Three terms appear in the table. The agent's own identity (ID2) means its own account, least privilege, short-lived credentials and a named sponsor. The delegation chain sets out that scale. The Rule of Two is Meta's test (31 October 2025). An agent should combine at most two of three things. They are untrusted input, sensitive data, and the power to change something or send data out. Plan-then-apply means the agent proposes a change, and a fixed system applies it after approval.

The map

Each kind of rule has one place where it is enforced. Each also has a place where people wrongly assume it is.

A worked example: a billing correction at a utility

A utility's billing agent proposes a corrected bill after a wrong meter read. The call goes to the billing system through the gateway. The gateway checks that this tool is on the agent's list. It adds a short-lived credential tied to the agent's identity, and it logs the call. The policy decision point then applies the rule. Is the confidence above the agreed level, and is the change under the hard limit? If yes, the bill is released, and a sample is checked later. If no, a specialist decides.

Suppose the agent notices that estimated reads after a meter swap are often wrong. That lesson does not change the agent's behaviour on its own. It becomes a fixed rule only after it passes the tests and a person approves it. The full design is on billing exceptions.

Evidence and limits

The three enforcement points follow 2026 guidance from regulators and security agencies. Six sources say model-based guardrails reduce risk but do not authorise anything. They are IMDA, the UK NCSC, the Five Eyes agencies, AWS, OWASP and Anthropic.

In published tests, about three in four attacks got past three named commercial guardrail products. One October 2025 study broke 12 published defences, most at above 90 percent, once attacks adapted.

There are fair counterpoints. IMDA and Google keep model checks where fixed rules cannot define the risk, such as harmful content. AWS lets a guardrail score feed a policy decision [vendor]. The ten categories and the tier matrix are expert judgement. No study links any tier or category to incident rates.

Next step

Follow company data into a cited answer on the data-to-memory pipeline.

Explore this topic

Bypass rates in full. In published tests, about 72 percent, 77 percent and 72.5 percent of attacks got past three named commercial guardrail products. Up to 100 percent got past some configurations. An October 2025 study (arXiv 2510.09023) broke 12 published defences, most at above 90 percent. Human red-teamers beat every one. NIST's agent-hijacking tests rose from 11 percent to 81 percent success once attacks were tuned to the defence (January 2025). Vendor figures on fixed benchmarks run far lower. The only setup with a measured 0 percent bypass rate paid for it. It had 16.22 percent false positives and about 1.5 seconds of added delay per call. A guardrail can also be made to refuse service, and that refusal can itself be exploited.

Newer checks. FIDES, in a major agent framework, scored zero policy-breaking injections on the AgentDojo benchmark, against 20 to 152 without it [vendor]. Its documentation (October 2026) marks it experimental and Python-only. It is not supported where code executes, and it is silent on file and network access. Where code runs, the sandbox, egress and credential controls carry the load.

The ceiling on promoted rules. Formal work shows fixed gates can enforce strictly less than edit automata, a stronger class of monitor. So some rules about behaviour over time, called renewal properties, stay out of reach.

Counterpoints. OpenAI's Agents SDK guardrails do not cover its built-in shell, computer and patch tools [vendor]. A guardrail inside a software development kit is not a boundary.

Sources by category. Input: OWASP cheat sheet; IMDA; Microsoft CAF [vendor]; ASD ISM (secondary). Output: AWS Bedrock Guardrails [vendor]; Microsoft CAF [vendor]. Tool and action: AWS AgentCore Policy [vendor]; OWASP; Five Eyes. Identity and access: Five Eyes; UK NCSC; ASD ISM (secondary). Data and egress: UK NCSC; Microsoft CAF [vendor]; MAS. Spend and rate: EY (1 June 2026); AWS AgentCore Policy [vendor]; Stripe [vendor]. Runtime isolation: UK NCSC; Claude Code and Codex docs [vendor]. Monitoring and kill switch: UK NCSC; MAS; NIST AI 600-1; Five Eyes. Change control: MAS; Microsoft CAF [vendor]. Human oversight: IMDA section 2.2.2; Five Eyes.

Cite this page

Written by Murali Sid, Founder and AI Systems Architect, last updated 15 October 2026. Licensed CC BY-SA 4.0, so quote it freely with attribution.

Murali Sid (2026). Enforcement outside the model. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/architecture/enforcement

Machine-readable version of this page: /architecture/enforcement.md

The agent lifecycle: register to retire

The nine stages every agent passes through, from registration to retirement. A registry entry and a named sponsor come first, before any credential, and retiring is more than switching off.

The data-to-memory pipeline

How company data becomes a cited answer and an agent memory in nine stages, and the rule that every copy keeps the original's access, privacy and deletion duties.

On this page

What a model can be talked intoEnforcement point 1: the gatewayEnforcement point 2: the policy decision pointEnforcement point 3: promoted rules, landed outside the modelWhat guardrails are forThe ten guardrail categoriesWhich categories apply at each risk tierThe mapA worked example: a billing correction at a utilityEvidence and limitsNext step