The model is not the perimeter

Tool-using models inherit a dangerous visual metaphor from chat interfaces. A request enters the model, a response leaves it, and the model appears to sit at the centre of control. In an operational system, however, the consequential path continues through credentials, APIs, queues, databases and physical or financial actuators. The model proposes a path through that machinery. It does not need to possess legitimate judgement for the machinery to constrain what happens next.

This distinction is older than language models. Secure systems separate an untrusted or fallible subject from the mechanism that mediates access. Saltzer and Schroeder’s principles of fail-safe defaults, least privilege and complete mediation remain useful because they make no assumption about the subject’s motives.[1] NIST’s zero-trust architecture similarly separates policy decision from policy enforcement and argues for granular, per-request authorisation close to the protected resource.[6] The language is different, but the causal idea is the same: a wish, plan or identity claim is not an effect.

The hidden assumption inside “the model will decide safely”

Model-centred control quietly assumes that the model can distinguish instruction from data, legitimate purpose from persuasive pretext, and authorised change from hostile suggestion. Indirect prompt injection targets exactly this assumption. AgentDojo formalised tool-using tasks in which externally supplied content can redirect an agent, and found that both task performance and security remain difficult under attack.[8] NIST’s generative AI profile also identifies direct and indirect prompt injection as information-security risks for integrated systems.[7]

The lesson is not that models never improve. It is that behavioural improvement and authority containment answer different questions. A better model may propose fewer dangerous actions. A containment boundary determines whether a dangerous proposal can become an effect. The first changes probability. The second can remove a class of outcomes, provided the boundary observes the right facts and mediates all routes.

CaMeL makes this separation explicit by placing a protective system layer around a potentially susceptible model, extracting control and data flow from the trusted request and using capabilities to constrain information flow.[9] Its reported benchmark result is promising but not universal: the evaluated implementation solved 77 per cent of AgentDojo tasks with its stated security guarantee. That number is evidence of a practical trade-off, not proof that one architecture covers every workflow.

This definition deliberately avoids claiming that the whole system is safe. It names a narrower achievement. A transfer limit can be independent of model behaviour. The truth of a generated explanation usually cannot. A recipient allowlist can be independently enforced. Whether paying that recipient serves the user’s real interests may still require semantic and human judgement. The next task is therefore property placement, not the search for one universal guardrail.

flowchart TD
  A["The invoice that politely asks<br/>to steal"] --> B["The model is not the perimeter"]
  B --> C["Find the enforcement frontier"]
  C --> D["Build the narrow authority kernel"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#5B5CF6,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Find the enforcement frontier

Suppose a team writes the policy “the agent may only perform safe actions”. The sentence sounds restrictive but gives an enforcement mechanism almost nothing to compute. Safe for whom, under which state, across what time, and measured at which effect? A property becomes implementable when it is translated into observations and decisions available at a specific boundary.

The useful question is not “can the model understand this rule?” It is “what is the narrowest mechanism that possesses the authoritative facts, sees every relevant effect and can refuse it?” That mechanism is the property’s enforcement frontier. Moving the property further inward makes it dependent on a larger, less predictable component. Moving it further outward may lose the context required to decide.

Four kinds of property

The gate reveals four practical classes. The first is boundary-enforceable: type, action name, resource, amount, destination, rate, expiry, identity and signature can often be checked directly. The second is boundary-verifiable: a business invariant such as sufficient funds or an approved supplier can be checked when the gateway queries authoritative state. The third is boundary-assisted: purpose, necessity, truthfulness and user benefit may be constrained by structured evidence, but still require semantic interpretation. The fourth is non-local: covert channels, cumulative manipulation and harms emerging across many individually permitted actions cannot be guaranteed by one action boundary.

This classification prevents two symmetrical mistakes. The first is under-claiming, where teams leave enforceable facts inside prompts. The second is over-claiming, where a deterministic gateway is said to guarantee a semantic property it cannot observe. The same architecture may therefore provide a hard guarantee for “no payment above £5,000” and only a defeasible check for “payment advances the stated business purpose”.

A capability is more than permission

An allowlist says that an action may exist. A capability says that a particular holder may exercise a particular authority under explicit constraints. Capability systems couple designation and authority, reducing the chance that a deputy interprets an attacker-supplied name using broad ambient privileges. Capsicum demonstrated practical capability confinement for Unix processes.[3] Macaroons showed how delegation credentials can be attenuated with contextual caveats such as who, where, when and for what purpose.[4]

For an agent, a useful grant should bind at least the actor runtime, the represented subject, the purpose, the permitted action types, named resources, parameter limits, information classes, validity interval, policy version and delegation lineage. These fields are not decorative metadata. They are the inputs that let the boundary distinguish “the agent can call payments” from “this runtime may pay this approved supplier up to this amount for this invoice during this short interval”.

{
  "request_id": "req-193-07",
  "actor": "agent/payables",
  "subject": "company/42",
  "purpose": "settle-approved-invoice",
  "action": "payment.create",
  "resource": "bank/operating",
  "parameters": {
    "to_account": "vendor/blue-orchard",
    "amount": "4870.00",
    "currency": "GBP",
    "invoice_id": "INV-2048"
  },
  "source_labels": ["internal"],
  "grant_id": "grant-7",
  "policy_version": 12,
  "idempotency_key": "invoice/INV-2048",
  "requested_at": "2030-01-01T12:00:00Z"
}

Exceptions must change authority, not bypass it

Real workflows contain exceptions. A supplier changes its bank account. A security incident requires an emergency deployment. A customer asks for an unusual disclosure. Teams often respond by adding an “override” flag that the model can set or by routing the request to a tool with broader permissions. That restores ambient authority at the moment of greatest uncertainty.

A safer exception is a new authority event. The boundary returns a denial code that names the missing condition. A separate principal reviews evidence and issues a narrower, short-lived grant for the exceptional value. The grant should record the approving identity, reason, evidence reference, maximum effect, expiry and whether a second approver is required. The original agent may continue the workflow, but it never manufactures the exception by explanation alone.

This design preserves flexibility without weakening the causal structure. The exceptional action still passes the same schema, freshness, execution and receipt path. Only the authoritative input changes. It also creates better operating evidence: reviewers can distinguish frequent legitimate exceptions from policy drift, adversarial pressure or a badly designed normal path. An exception is a scoped change in authority, not permission to leave the boundary.

The rule also tells us when to stop. If a boundary cannot observe a property, do not hide the gap behind an “AI safety” label. Move an authoritative fact to the boundary, add a verifiable predicate, introduce a labelled data-flow mechanism, or downgrade the claim from guarantee to monitored judgement. Honest placement is already a major improvement because it makes the residual dependence on model behaviour visible.

Build the narrow authority kernel

Once properties have been placed, the architecture becomes less mysterious. The model receives context and proposes an action. A small authority kernel converts the proposal into a decision about a declared effect. The kernel should be much smaller than the model and orchestration stack because its trust burden is different. It must be understandable, testable and, for high-consequence systems, amenable to formal or machine-checked assurance.

The seL4 project is a useful exemplar, not a direct proof for agent systems. Its significance here is architectural: a deliberately small kernel with explicit specifications can support much stronger assurance than a large general-purpose component.[5] An agent containment kernel need not be an operating-system microkernel, but it should borrow the discipline of a small trusted computing base. Model weights, prompts, retrieved documents, generated code and planning traces should remain outside that base wherever possible.

Seven transitions, not one tool call

A raw tool call collapses proposal, authority and execution into one moment. A contained action should instead pass through seven transitions. First, the model emits a proposal with no ambient credential. Second, a normaliser validates a closed schema and rejects unknown fields. Third, a policy decision checks the grant against actor, subject, purpose, action, resource and parameter constraints. Fourth, authoritative state supplies fresh preconditions. Fifth, the effect gateway executes with an idempotency key and transaction semantics appropriate to reversibility. Sixth, the system records an effect receipt. Seventh, an independent read path verifies the postcondition.

NIST’s policy decision point and policy enforcement point provide a useful separation between deciding and enforcing access.[6] Agent systems need to extend that separation because “access” may be a state-changing workflow rather than a connection. A permission decision alone does not tell us whether an effect ran, ran twice, partly ran or became unknowable after a timeout. The receipt and readback steps turn authorisation into governed execution.

The containment specification

The smallest useful implementation should support one consequential action class end to end. Choose a payment, message, record update or deployment change. Define a closed request type. Define the authoritative state and the issuer of capabilities. Specify denial reasons as stable machine-readable codes. Specify idempotency and timeout behaviour. Specify the effect receipt and an independent readback query. Then inject failures at every transition.

The following specification is intentionally stricter than a typical tool schema. It encodes four invariants. No effect without a grant. No grant is interpreted without binding actor, subject and purpose. No grant survives expiry or a policy-version change. No duplicated request creates a duplicated effect. It adds a lightweight information-flow rule so that confidential input cannot be sent to an external sink even when read and send operations are individually permitted.

Complete mediation must be demonstrated

Complete mediation is an architectural claim, not a line in a policy file. Demonstrate it by inventorying credentials, network routes, queues, code-execution facilities, service identities and human-operated consoles. The model runtime should receive no credential that can directly realise the protected effect. Generated code should execute in a domain that exposes only the capability-safe facade. Downstream workers must reject requests that lack boundary-issued evidence rather than trusting their network location.

Then test the negative space. Attempt the effect through an older API version, a batch endpoint, a retry queue, a delegated sub-agent, a cached credential and a recovery console. Rotate or revoke the capability during each path. If any route can produce the effect without the same invariant checks, the property is not model-independent. This is also where operational simplification matters. Every additional execution path enlarges the trusted base and the proof obligation.

Choose a scenario, then run the boundary.

from __future__ import annotations

from dataclasses import dataclass, field, asdict
from datetime import datetime, timedelta, timezone
from decimal import Decimal
from hashlib import sha256
from typing import Any, FrozenSet, Literal, Mapping
import json

Action = Literal["payment.create", "message.send"]
DecisionKind = Literal["allow", "deny", "replay"]
Label = Literal["public", "internal", "confidential"]


@dataclass(frozen=True)
class Grant:
    grant_id: str
    actor: str
    subject: str
    purpose: str
    actions: FrozenSet[Action]
    resources: FrozenSet[str]
    recipients: FrozenSet[str]
    max_amount: Decimal
    issued_at: datetime
    expires_at: datetime
    policy_version: int


@dataclass(frozen=True)
class ActionRequest:
    request_id: str
    actor: str
    subject: str
    purpose: str
    action: Action
    resource: str
    parameters: Mapping[str, Any]
    source_labels: FrozenSet[Label]
    grant_id: str
    policy_version: int
    idempotency_key: str
    requested_at: datetime


@dataclass(frozen=True)
class Decision:
    kind: DecisionKind
    reason: str
    checks: tuple[str, ...]


@dataclass(frozen=True)
class EffectReceipt:
    effect_id: str
    request_id: str
    action: Action
    resource: str
    parameters_hash: str
    policy_version: int
    verified: bool
    replayed: bool = False


@dataclass
class AuthoritativeState:
    policy_version: int
    approved_vendor_accounts: set[str]
    balances: dict[str, Decimal]
    sent_messages: list[dict[str, Any]] = field(default_factory=list)
    payments: list[dict[str, Any]] = field(default_factory=list)


class ContainmentKernel:
    """A small, deterministic reference monitor for agent-proposed effects."""

    def __init__(self, state: AuthoritativeState, grants: Mapping[str, Grant]):
        self.state = state
        self.grants = dict(grants)
        self.receipts_by_key: dict[str, EffectReceipt] = {}

    def evaluate(self, req: ActionRequest, now: datetime) -> Decision:
        checks: list[str] = []
        grant = self.grants.get(req.grant_id)
        if grant is None:
            return Decision("deny", "unknown_grant", tuple(checks))
        checks.append("grant_exists")

        if (req.actor, req.subject, req.purpose) != (
            grant.actor,
            grant.subject,
            grant.purpose,
        ):
            return Decision("deny", "actor_subject_or_purpose_mismatch", tuple(checks))
        checks.append("actor_subject_purpose_bound")

        if req.action not in grant.actions or req.resource not in grant.resources:
            return Decision("deny", "action_or_resource_out_of_scope", tuple(checks))
        checks.append("action_resource_scoped")

        if not (grant.issued_at <= now <= grant.expires_at):
            return Decision("deny", "grant_not_fresh", tuple(checks))
        checks.append("grant_fresh")

        if req.policy_version != self.state.policy_version:
            return Decision("deny", "stale_policy_version", tuple(checks))
        if grant.policy_version != self.state.policy_version:
            return Decision("deny", "grant_issued_under_old_policy", tuple(checks))
        checks.append("policy_fresh")

        if req.idempotency_key in self.receipts_by_key:
            return Decision("replay", "existing_effect_receipt", tuple(checks))
        checks.append("not_previously_executed")

        if req.action == "payment.create":
            allowed = {"from_account", "to_account", "amount", "currency", "invoice_id"}
            if set(req.parameters) != allowed:
                return Decision("deny", "payment_schema_mismatch", tuple(checks))
            checks.append("typed_payment_schema")

            amount = Decimal(str(req.parameters["amount"]))
            recipient = str(req.parameters["to_account"])
            source = str(req.parameters["from_account"])
            if amount <= 0 or amount > grant.max_amount:
                return Decision("deny", "amount_out_of_scope", tuple(checks))
            checks.append("amount_within_limit")
            if recipient not in grant.recipients:
                return Decision("deny", "recipient_not_in_grant", tuple(checks))
            if recipient not in self.state.approved_vendor_accounts:
                return Decision("deny", "recipient_not_authoritative", tuple(checks))
            checks.append("recipient_authorised")
            if self.state.balances.get(source, Decimal("0")) < amount:
                return Decision("deny", "insufficient_funds", tuple(checks))
            checks.append("precondition_holds")

        elif req.action == "message.send":
            allowed = {"recipient", "body"}
            if set(req.parameters) != allowed:
                return Decision("deny", "message_schema_mismatch", tuple(checks))
            checks.append("typed_message_schema")
            recipient = str(req.parameters["recipient"])
            if recipient not in grant.recipients:
                return Decision("deny", "recipient_not_in_grant", tuple(checks))
            checks.append("recipient_authorised")
            if "confidential" in req.source_labels and recipient.endswith("@external.example"):
                return Decision("deny", "confidential_to_external_sink", tuple(checks))
            checks.append("information_flow_allowed")

        return Decision("allow", "all_checks_passed", tuple(checks))

    def execute(self, req: ActionRequest, now: datetime) -> tuple[Decision, EffectReceipt | None]:
        decision = self.evaluate(req, now)
        if decision.kind == "deny":
            return decision, None
        if decision.kind == "replay":
            old = self.receipts_by_key[req.idempotency_key]
            return decision, EffectReceipt(**{**asdict(old), "replayed": True})

        payload = json.dumps(dict(req.parameters), sort_keys=True, default=str).encode()
        effect_id = sha256(req.idempotency_key.encode() + payload).hexdigest()[:16]

        if req.action == "payment.create":
            amount = Decimal(str(req.parameters["amount"]))
            source = str(req.parameters["from_account"])
            self.state.balances[source] -= amount
            self.state.payments.append({"effect_id": effect_id, **dict(req.parameters)})
            verified = any(p["effect_id"] == effect_id for p in self.state.payments)
        else:
            self.state.sent_messages.append({"effect_id": effect_id, **dict(req.parameters)})
            verified = any(m["effect_id"] == effect_id for m in self.state.sent_messages)

        receipt = EffectReceipt(
            effect_id=effect_id,
            request_id=req.request_id,
            action=req.action,
            resource=req.resource,
            parameters_hash=sha256(payload).hexdigest(),
            policy_version=self.state.policy_version,
            verified=verified,
        )
        self.receipts_by_key[req.idempotency_key] = receipt
        return decision, receipt


def build_demo() -> tuple[ContainmentKernel, Grant, datetime]:
    now = datetime(2030, 1, 1, 12, 0, tzinfo=timezone.utc)
    grant = Grant(
        grant_id="grant-7",
        actor="agent/payables",
        subject="company/42",
        purpose="settle-approved-invoice",
        actions=frozenset({"payment.create", "message.send"}),
        resources=frozenset({"bank/operating", "mail/payables"}),
        recipients=frozenset({"vendor/blue-orchard", "ap@company.example"}),
        max_amount=Decimal("5000"),
        issued_at=now - timedelta(minutes=5),
        expires_at=now + timedelta(minutes=10),
        policy_version=12,
    )
    state = AuthoritativeState(
        policy_version=12,
        approved_vendor_accounts={"vendor/blue-orchard"},
        balances={"bank/operating": Decimal("25000")},
    )
    return ContainmentKernel(state, {grant.grant_id: grant}), grant, now


def scenario_requests(grant: Grant, now: datetime) -> dict[str, ActionRequest]:
    common = dict(
        actor=grant.actor,
        subject=grant.subject,
        purpose=grant.purpose,
        grant_id=grant.grant_id,
        policy_version=12,
        requested_at=now,
    )
    return {
        "legitimate": ActionRequest(
            request_id="req-1",
            action="payment.create",
            resource="bank/operating",
            parameters={
                "from_account": "bank/operating",
                "to_account": "vendor/blue-orchard",
                "amount": "4870.00",
                "currency": "GBP",
                "invoice_id": "INV-2048",
            },
            source_labels=frozenset({"internal"}),
            idempotency_key="invoice/INV-2048",
            **common,
        ),
        "injected_recipient": ActionRequest(
            request_id="req-2",
            action="payment.create",
            resource="bank/operating",
            parameters={
                "from_account": "bank/operating",
                "to_account": "vendor/attacker",
                "amount": "4870.00",
                "currency": "GBP",
                "invoice_id": "INV-2048",
            },
            source_labels=frozenset({"internal"}),
            idempotency_key="invoice/INV-2048-attacker",
            **common,
        ),
        "stale_grant": ActionRequest(
            request_id="req-3",
            action="payment.create",
            resource="bank/operating",
            parameters={
                "from_account": "bank/operating",
                "to_account": "vendor/blue-orchard",
                "amount": "120.00",
                "currency": "GBP",
                "invoice_id": "INV-OLD",
            },
            source_labels=frozenset({"internal"}),
            idempotency_key="invoice/INV-OLD",
            **common,
        ),
        "confidential_exfiltration": ActionRequest(
            request_id="req-4",
            action="message.send",
            resource="mail/payables",
            parameters={"recipient": "leak@external.example", "body": "Quarterly forecast"},
            source_labels=frozenset({"confidential"}),
            idempotency_key="message/leak-1",
            **common,
        ),
    }


def run_demo() -> None:
    kernel, grant, now = build_demo()
    requests = scenario_requests(grant, now)

    results: dict[str, Any] = {}
    decision, receipt = kernel.execute(requests["legitimate"], now)
    results["legitimate"] = {"decision": asdict(decision), "receipt": asdict(receipt) if receipt else None}

    decision, receipt = kernel.execute(requests["injected_recipient"], now)
    results["injected_recipient"] = {"decision": asdict(decision), "receipt": receipt}

    decision, receipt = kernel.execute(requests["stale_grant"], now + timedelta(hours=1))
    results["stale_grant"] = {"decision": asdict(decision), "receipt": receipt}

    # Use a grant that actually names the external recipient so the flow label, not the allowlist, decides.
    external_grant = Grant(**{**asdict(grant), "grant_id": "grant-8", "recipients": frozenset({"leak@external.example"})})
    kernel.grants[external_grant.grant_id] = external_grant
    exfil = ActionRequest(**{**asdict(requests["confidential_exfiltration"]), "grant_id": "grant-8"})
    decision, receipt = kernel.execute(exfil, now)
    results["confidential_exfiltration"] = {"decision": asdict(decision), "receipt": receipt}

    decision, receipt = kernel.execute(requests["legitimate"], now)
    results["replay"] = {"decision": asdict(decision), "receipt": asdict(receipt) if receipt else None}

    assert results["legitimate"]["decision"]["kind"] == "allow"
    assert results["legitimate"]["receipt"]["verified"] is True
    assert results["injected_recipient"]["decision"]["reason"] == "recipient_not_in_grant"
    assert results["stale_grant"]["decision"]["reason"] == "grant_not_fresh"
    assert results["confidential_exfiltration"]["decision"]["reason"] == "confidential_to_external_sink"
    assert results["replay"]["decision"]["kind"] == "replay"
    assert len(kernel.state.payments) == 1

    print(json.dumps(results, indent=2, default=str))


if __name__ == "__main__":
    run_demo()

What a passing harness permits

A passing result permits a narrow statement: for the tested action type, declared threat model and implemented paths, these requests cannot bypass the encoded constraints through the reference interface. It justifies replacing vague claims such as “the agent is guarded” with explicit claims such as “the payment gateway rejects ungranted recipients, expired grants, stale policy versions, confidential-to-external flows and duplicate invoice effects”.

It does not establish that the invoice is genuine, that the approved supplier is honest, that the policy author chose wise limits or that the runtime has no exploitable bug. It also does not show complete mediation. That must be established architecturally by removing direct credentials from the model, generated code and orchestration layer, then testing for alternate paths. A model-independent property is only as strong as the boundary’s monopoly over the effect.

stateDiagram-v2
  [*] --> Claim
  state "The hidden assumption inside<br/>“the model will decide safely”" as Claim
  state "Four kinds of property" as Test
  state "A capability is more than<br/>permission" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Where the guarantees stop

A containment boundary is valuable partly because it can say no. It must also say “not established”. The strongest failure mode is specification error: the boundary faithfully enforces the wrong property. A grant may name the attacker because the supplier system was compromised. A £5,000 limit may be unsafe when repeated across hundreds of transactions. A policy may permit a public message whose wording manipulates a market. Deterministic enforcement does not turn a bad rule into a good one.

The second limit is observability. A boundary can block a confidential value when the value carries a reliable label. It cannot always recognise that an apparently ordinary sentence encodes the same secret. It may constrain network destinations and message size yet still miss a timing channel. The 2026 tracked-capabilities work explicitly treats correctness and covert channels as non-goals, which is the right kind of boundary statement rather than a weakness to conceal.[10]

The semantic residue

Purpose binding illustrates the difference between a constraint and a proof. A capability may say “settle-approved-invoice”. The boundary can require the request to carry that purpose and can check that the grant permits it. But deciding whether a novel action genuinely serves that purpose may still require evidence, interpretation or human review. The typed field prevents silent purpose drift; it does not create semantic certainty.

Similarly, an effect receipt proves that an API accepted or recorded an operation under a stated policy version. It does not by itself prove the external world changed as intended. That is why readback should use a different path where possible. Even then, correlated failure remains possible if execution and verification depend on the same compromised source. Receipts improve reconstructability. They are not metaphysical truth.

Recent agent-security work increasingly organises risk around boundaries, tools, memory, identity and cross-agent propagation.[12] OWASP’s agentic guidance provides a useful operational inventory of threats, but inventories do not determine where a property becomes enforceable.[13] The enforcement-frontier test adds that missing design question: what can this boundary actually observe, decide and stop?

The strongest alternative: make the model itself trustworthy

An alignment-centred approach argues that external rules become brittle, block useful novelty and cannot enumerate every legitimate exception. A model that understands intent can adapt to context, recognise deception and decline actions that pass superficial checks. This is a strong argument for improving models and semantic assessors. A purely syntactic kernel can be safely useless.

The alternative fails only when it is asked to carry authority alone. Model judgement is valuable for proposal quality, anomaly detection, explanation and escalation. It should help determine which capability to request and which evidence to surface. Yet the final release of a consequential effect should still cross a mechanism whose decision does not depend on the model remaining honest. Alignment and containment are complements: alignment reduces dangerous proposals; containment limits what any proposal can do.

sequenceDiagram
  participant Q as Question
  participant M as Mechanism
  participant E as Evidence
  participant D as Decision
  Q->>M: The invoice that politely asks to steal
  M->>E: The hidden assumption inside “the model will decide safely”
  E-->>M: compare rival explanations
  E->>D: Move safety properties to the boundary that can deny
  D-->>Q: revise scope or act

Move safety properties to the boundary that can deny

Do not ask whether a model is trustworthy enough to receive a powerful tool. Ask which effect properties must remain true when the model is mistaken, manipulated or openly hostile. Then place each property where the system can observe authoritative facts, mediate every path and deny the effect.

For a new agent, this changes the build order. Begin with the effect inventory, not the prompt. Define typed actions and irreversible outcomes. Identify the authoritative source for identity, purpose, state and limits. Issue narrow, expiring capabilities. Put complete mediation at the effect gateway. Couple fresh authorisation to execution. Produce an effect receipt and verify the postcondition through an independent read path. Only then optimise the model’s planning quality.

For an existing agent, run the substitution test. Replace the model conceptually with an arbitrary program that can emit any valid request. List every claimed safety property that fails under that replacement. Those properties still live inside model behaviour. Either move them to a boundary, supply the missing authoritative state, add information-flow control, or relabel them as monitored semantic judgements.

The practical decision is to grant models proposal power, not ambient authority. A model may search, infer, compare and recommend widely. Its ability to change the world should be expressed through typed, scoped and revocable capabilities whose enforcement does not care why the model asked. This does not solve agent safety. It creates a defensible floor beneath it.