{
  "schemaVersion": "1.0",
  "type": "research-article",
  "runtimeAvailable": false,
  "id": "proof21:journal:let-agents-explain-let-controls-decide:en",
  "inLanguage": "en",
  "slug": "let-agents-explain-let-controls-decide",
  "title": "Let agents explain. Let controls decide.",
  "description": "A readable explanation is useful, but permissions, evidence checks, and irreversible actions need explicit enforcement outside the narrative.",
  "datePublished": "2026-09-07",
  "dateModified": "2026-09-07",
  "url": "https://proof21.xyz/journal/let-agents-explain-let-controls-decide/",
  "markdownUrl": "https://proof21.xyz/journal/let-agents-explain-let-controls-decide/article.md",
  "markdown": "# Let agents explain. Let controls decide.\n\n**Security design note · 7 September 2026 · A proposed architecture, not a security certification.**\n\nAn agent can explain why a report appears to match a request. That explanation may be genuinely helpful. It is still not the same thing as checking the report's authenticated bytes, comparing exact transaction fields, or authorizing a transfer. A system that lets persuasive prose stand in for those operations has put the decision boundary in the wrong place.\n\nProof21's proposed role is evidence, not custody or unrestricted execution. The report should make specific checks easier to reproduce. A separate consumer policy decides what the evidence permits next. This leaves room for capable agents without asking the language model to be the sole guardian of funds, credentials, or production settings.\n\n## Treat retrieved content as data, even when it sounds authoritative\n\nA retrieved document, tool response, or inscription can contain text that looks like an instruction. Its confidence or formatting does not give it authority over the user's task. OWASP's prompt-injection guidance treats indirect content and tool-related effects as important attack surfaces and recommends layered controls rather than reliance on a single reassuring prompt. [1]\n\nIn a proposed checking workflow, the producer's explanation belongs to the evidence being assessed. It must not be allowed to change the consumer's trusted recipient, policy threshold, allowed host list, or approval requirement. Keep the original user instruction and the configured policy available separately from material supplied by the party being evaluated.\n\nResearch such as CaMeL explores architectural separation of control and data flows and capability-based restrictions around model tool use. It is a useful research reference, not evidence that Proof21 implements that system or inherits its evaluated guarantees. A design must be judged by its own implementation and tests. [2]\n\n## Separate reading, checking, approving, and acting\n\nConsider a synthetic accounts-payable assistant. Its first job is to read an invoice and associated evidence. A checker then compares supported fields with an authorized instruction. A controller evaluates whether the result is sufficient, and an authorized execution system may perform an action only after the necessary approval. These are separate stages even if the user sees a compact interface.\n\nThe reading stage should not need a payment signing key. The checking stage should not silently gain permission to send funds because it found a mismatch. The explanation stage should not be able to edit the original instruction. When practical, separate credentials and processes so these boundaries are enforced by the system rather than merely requested in prose.\n\nKeep the action itself exact. Approval of one recipient, asset, network, and integer amount must not become approval of a later modified payload. Bind the reviewed operation and its expiry or freshness conditions to the final action. Recheck the relevant state when it can change between review and execution. A stale approval should not become an open-ended permission slip.\n\n## An unresolved result is not permission to improvise\n\nWhen required evidence is unavailable, a checker should report `INDETERMINATE` with the missing dependency. The next step may be waiting, requesting additional evidence, or escalating to an authorized person. It should not be an agent quietly switching providers, altering the policy, or retrying an irreversible action just to produce a positive-looking outcome.\n\nLikewise, an authentic negative report can be useful. A controller may accept it for monitoring or investigation while rejecting the next financial action. The distinction between artifact integrity, claim evaluation, and local acceptance is not bureaucratic overhead; it prevents a valid signature from becoming an unintended permission grant.\n\nNetwork access needs a similar boundary. Evidence URLs should not be fetched with unrestricted ambient credentials. Bound destinations, redirects, response sizes, and timeouts, and keep secrets out of logs and model-visible material. MCP security guidance discusses token passthrough and intermediary risks; an integration must preserve the intended audience and authority of credentials. [3]\n\n## Human approval should show the decision, not hide it\n\nA useful approval screen names the exact action and material differences from the original instruction. Show the recipient, network, asset, amount, evidence status, and policy result in a form the reviewer can inspect. Do not ask a person to approve a vague statement such as “complete the workflow” while hiding the actual payload behind a friendly summary.\n\nApproval also needs scope. Reading a report is not approval to publish it. Running an offline demo is not approval to connect a wallet. Reviewing a release is not approval to change DNS, billing, repository visibility, or a production deployment. A well-designed controller carries these distinctions through to the tools that perform the work.\n\nThe refusal path should be usable. A reviewer must be able to reject or request clarification without the application repeatedly presenting the same action as inevitable. Record the decision and its context while avoiding unnecessary retention of sensitive data. A readable audit trail is useful only when it describes what actually happened.\n\n## Test the boundary rather than the sales claim\n\nA pilot should place misleading instructions inside synthetic evidence and confirm that they cannot change the configured policy or action scope. Test an altered recipient after approval, an expired approval, the wrong operation identifier, an unsupported report version, and a failed evidence fetch. Include a successful legitimate case so a system that rejects everything is not mistaken for a useful solution.\n\nMeasure unauthorized actions prevented, legitimate tasks completed, unresolved cases escalated, and the effort needed to understand a decision. Keep fixture results separate from production observations. No finite test pack establishes universal immunity to prompt injection, and a model-based guardrail is still a component that needs its own threat model.\n\nThe current Proof21 offline demo intentionally avoids wallets, network calls, and real payments. That makes it a safer educational starting point, not a finished production control plane. The next implementation should preserve those explicit boundaries while adding reviewed capabilities one at a time, with reproducible evidence and a consumer that retains authority.\n\n## Frequently asked questions\n\n### Should an LLM be the only verifier of a cryptographic artifact?\n\nNo. Use supported deterministic parsing, cryptographic verification, and policy checks for exact claims. The model can explain results and help people navigate evidence, but its narrative must not replace those checks.\n\n### Does a failed check authorize the agent to repair the payment?\n\nNo. A mismatch is evidence, not a permission grant. Any corrective action requires the application's own authorization, exact payload review, and protections against duplicate or unintended actions.\n\n### Do these controls guarantee that prompt injection is impossible?\n\nNo such guarantee is made. They define testable boundaries and layered defenses. Their effectiveness depends on the actual implementation, deployment, supported threat model, and continued review.\n\n## Primary and academic references\n\n- [1: OWASP — LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)\n- [2: Debenedetti et al. — Defeating Prompt Injections by Design](https://arxiv.org/abs/2503.18813)\n- [3: MCP — Security Best Practices](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices)\n- [Proof21 security boundaries](https://proof21.xyz/docs/protocol/security/)\n- [The offline demo and its limits](https://proof21.xyz/docs/start/offline-demo/)\n",
  "articleBody": "Security design note · 7 September 2026 · A proposed architecture, not a security certification. An agent can explain why a report appears to match a request. That explanation may be genuinely helpful. It is still not the same thing as checking the report's authenticated bytes, comparing exact transaction fields, or authorizing a transfer. A system that lets persuasive prose stand in for those operations has put the decision boundary in the wrong place. Proof21's proposed role is evidence, not custody or unrestricted execution. The report should make specific checks easier to reproduce. A separate consumer policy decides what the evidence permits next. This leaves room for capable agents without asking the language model to be the sole guardian of funds, credentials, or production settings. Treat retrieved content as data, even when it sounds authoritative A retrieved document, tool response, or inscription can contain text that looks like an instruction. Its confidence or formatting does not give it authority over the user's task. OWASP's prompt-injection guidance treats indirect content and tool-related effects as important attack surfaces and recommends layered controls rather than reliance on a single reassuring prompt. [1] In a proposed checking workflow, the producer's explanation belongs to the evidence being assessed. It must not be allowed to change the consumer's trusted recipient, policy threshold, allowed host list, or approval requirement. Keep the original user instruction and the configured policy available separately from material supplied by the party being evaluated. Research such as CaMeL explores architectural separation of control and data flows and capability-based restrictions around model tool use. It is a useful research reference, not evidence that Proof21 implements that system or inherits its evaluated guarantees. A design must be judged by its own implementation and tests. [2] Separate reading, checking, approving, and acting Consider a synthetic accounts-payable assistant. Its first job is to read an invoice and associated evidence. A checker then compares supported fields with an authorized instruction. A controller evaluates whether the result is sufficient, and an authorized execution system may perform an action only after the necessary approval. These are separate stages even if the user sees a compact interface. The reading stage should not need a payment signing key. The checking stage should not silently gain permission to send funds because it found a mismatch. The explanation stage should not be able to edit the original instruction. When practical, separate credentials and processes so these boundaries are enforced by the system rather than merely requested in prose. Keep the action itself exact. Approval of one recipient, asset, network, and integer amount must not become approval of a later modified payload. Bind the reviewed operation and its expiry or freshness conditions to the final action. Recheck the relevant state when it can change between review and execution. A stale approval should not become an open-ended permission slip. An unresolved result is not permission to improvise When required evidence is unavailable, a checker should report INDETERMINATE with the missing dependency. The next step may be waiting, requesting additional evidence, or escalating to an authorized person. It should not be an agent quietly switching providers, altering the policy, or retrying an irreversible action just to produce a positive-looking outcome. Likewise, an authentic negative report can be useful. A controller may accept it for monitoring or investigation while rejecting the next financial action. The distinction between artifact integrity, claim evaluation, and local acceptance is not bureaucratic overhead; it prevents a valid signature from becoming an unintended permission grant. Network access needs a similar boundary. Evidence URLs should not be fetched with unrestricted ambient credentials. Bound destinations, redirects, response sizes, and timeouts, and keep secrets out of logs and model-visible material. MCP security guidance discusses token passthrough and intermediary risks; an integration must preserve the intended audience and authority of credentials. [3] Human approval should show the decision, not hide it A useful approval screen names the exact action and material differences from the original instruction. Show the recipient, network, asset, amount, evidence status, and policy result in a form the reviewer can inspect. Do not ask a person to approve a vague statement such as “complete the workflow” while hiding the actual payload behind a friendly summary. Approval also needs scope. Reading a report is not approval to publish it. Running an offline demo is not approval to connect a wallet. Reviewing a release is not approval to change DNS, billing, repository visibility, or a production deployment. A well-designed controller carries these distinctions through to the tools that perform the work. The refusal path should be usable. A reviewer must be able to reject or request clarification without the application repeatedly presenting the same action as inevitable. Record the decision and its context while avoiding unnecessary retention of sensitive data. A readable audit trail is useful only when it describes what actually happened. Test the boundary rather than the sales claim A pilot should place misleading instructions inside synthetic evidence and confirm that they cannot change the configured policy or action scope. Test an altered recipient after approval, an expired approval, the wrong operation identifier, an unsupported report version, and a failed evidence fetch. Include a successful legitimate case so a system that rejects everything is not mistaken for a useful solution. Measure unauthorized actions prevented, legitimate tasks completed, unresolved cases escalated, and the effort needed to understand a decision. Keep fixture results separate from production observations. No finite test pack establishes universal immunity to prompt injection, and a model-based guardrail is still a component that needs its own threat model. The current Proof21 offline demo intentionally avoids wallets, network calls, and real payments. That makes it a safer educational starting point, not a finished production control plane. The next implementation should preserve those explicit boundaries while adding reviewed capabilities one at a time, with reproducible evidence and a consumer that retains authority. Frequently asked questions Should an LLM be the only verifier of a cryptographic artifact? No. Use supported deterministic parsing, cryptographic verification, and policy checks for exact claims. The model can explain results and help people navigate evidence, but its narrative must not replace those checks. Does a failed check authorize the agent to repair the payment? No. A mismatch is evidence, not a permission grant. Any corrective action requires the application's own authorization, exact payload review, and protections against duplicate or unintended actions. Do these controls guarantee that prompt injection is impossible? No such guarantee is made. They define testable boundaries and layered defenses. Their effectiveness depends on the actual implementation, deployment, supported threat model, and continued review. Primary and academic references 1: OWASP — LLM Prompt Injection Prevention Cheat Sheet 2: Debenedetti et al. — Defeating Prompt Injections by Design 3: MCP — Security Best Practices Proof21 security boundaries The offline demo and its limits",
  "citations": [
    "https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html",
    "https://arxiv.org/abs/2503.18813",
    "https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices"
  ],
  "faq": [
    {
      "question": "Should an LLM be the only verifier of a cryptographic artifact?",
      "answer": "No. Use supported deterministic parsing, cryptographic verification, and policy checks for exact claims. The model can explain results and help people navigate evidence, but its narrative must not replace those checks."
    },
    {
      "question": "Does a failed check authorize the agent to repair the payment?",
      "answer": "No. A mismatch is evidence, not a permission grant. Any corrective action requires the application's own authorization, exact payload review, and protections against duplicate or unintended actions."
    },
    {
      "question": "Do these controls guarantee that prompt injection is impossible?",
      "answer": "No such guarantee is made. They define testable boundaries and layered defenses. Their effectiveness depends on the actual implementation, deployment, supported threat model, and continued review."
    }
  ],
  "sourceSha256": "69af8b942e9e9c65d11f2a89a036aa64246008db7a948008bf8ffacabc33605e",
  "markdownSha256": "885153aeaa1740a72d04096a8665bbb613df96de6c7297bc870a12aa0b26706c",
  "translationReview": "Original English edition; not an independent technical audit.",
  "image": {
    "url": "https://proof21.xyz/assets/journal/controls.png",
    "caption": "A bounded path passes through a separate control gate. The illustration represents an authorization boundary, not a guarantee that a model cannot be manipulated.",
    "sha256": "c913abbd7a46f1fb738f737ea2b8ed40f5e7d6f6b90f5aae228d4b5f46563a39"
  },
  "motion": {
    "url": "https://proof21.xyz/assets/journal/controls.mp4",
    "engine": "Remotion",
    "sourceSha256": "13a909f4267d8147386045cbd90df732a42679342c16e04c5725e09e953d3728",
    "sha256": "f3dd827ef5b2c1e4be140bf39b779e01db82ac23f4aaf058d43e92265d6d22d8",
    "seconds": 7.2,
    "loop": true,
    "audio": false
  },
  "availableLanguages": [
    "en",
    "zh-Hans",
    "th",
    "ar"
  ],
  "editions": {
    "en": "https://proof21.xyz/journal/let-agents-explain-let-controls-decide/",
    "zh-Hans": "https://proof21.xyz/zh-hans/journal/let-agents-explain-let-controls-decide/",
    "th": "https://proof21.xyz/th/journal/let-agents-explain-let-controls-decide/",
    "ar": "https://proof21.xyz/ar/journal/let-agents-explain-let-controls-decide/"
  }
}