# A policy beside the prompt: what changed in v1.1.0, sgit.ai > The changes to the article "A policy beside the prompt" in v1.1.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [A policy beside the prompt](../../a-policy-beside-the-prompt.md) / [Versions](../a-policy-beside-the-prompt.md) / v1.1.0 # A policy beside the prompt: what changed in v1.1.0 From v1.0.0 (2026-10-13, `e22357971`) to v1.1.0 (2026-10-13, `8ef6586b3`), paragraph by paragraph. 12 paragraphs added, 0 removed, 3 changed in place, 52 unchanged. About 846 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [all versions](../a-policy-beside-the-prompt.md) · [v1.2.0 →](v1.2.0.md) 1 unchanged paragraph Summary: An idea came up while I was answering a post about agent liability, and I think it deserves to stand on its own as a proposal. Today an agent gets a prompt from us and a system prompt from its vendor. It should also get an Agent Behaviour Policy, written to a published standard, which the vendor accepts, enforces as far as it can, and eventually answers for. It is the beginning of dealing with something the models have got away with for a long time: they do not separate code from data, so every instruction and every piece of content arrives in the same channel. Now that agents can do a great deal, and are starting to go off the rails in public, their behaviour is becoming an existential threat to the companies that make them, through liability and above all through trust: it does not take many users being hurt before people stop giving agents instructions at all. Two industries have been here. Aviation did not get safe out of altruism; it got safe because every crash became world news, and at the accident rate of 1995 today's traffic would bring about a hundred fatal airliner accidents a year instead of twelve. Payments got some of the best security teams anywhere because liability for fraud was moved onto the card companies and the banks, and the fraud detection followed the money, often spotting a merchant's breach before the merchant did. Regulation alone does not do it; some industries are happy to pay the fines. It works when the rule, the liability and the business model point the same way. A policy beside the prompt is how to make them point the same way for agents: the user answers for what is outside the policy, and the vendor for the rows it accepted. Most agents already run a policy of their own; we just cannot see it, rely on it, or stop it changing. And the system prompt itself is a light behaviour policy that is not written like one: the next step is for the vendor's own rules to become a published policy too, layered with ours. !shot pp-inputs.webp | images/ | What an agent is givengiven,today,today in two modes and whatasthisproposed.proposes.OverTodaythe API we write the whole system prompt, so our behaviour policy goes inside it; in the Claude apps and Claude Code the vendor's system prompt comes first and our promptpolicyarrivegoes into what we add. In both, it is text the model is asked to keep, in onethe same channel withas every email,email and page and file the agentit reads, and the vendor's own ruleschecks are invisible.its own. Proposed: a behaviourthe policy as a separate, versioned input, besidelayered over the vendor's own published policy, eachcheckedrowoutsidemarkedthewithmodelwhat enforceswhere it andcanwho answers if it breaks.be. | diagram 9 unchanged paragraphs, under In short {#in-short} • **The policy goes into both modes, and today both are hope.** Over the API we write the whole prompt; in the Claude apps and Claude Code the vendor adds its own system prompt and we add ours. Either way the policy is text the model is asked to keep, which is why the checks have to get stronger. • **A system prompt is a light behaviour policy.** It tells the agent how to behave. It should be written as one, layered: the vendor's policy, then the deployer's, with business logic only the deployer can write. 30 unchanged paragraphs, under The idea: a policy beside the prompt {#idea}, The old problem: code and data in one channel {#code-and-data}, Why the vendors should want this {#existential}… ## Where the policy goes today, in each mode {#modes} The figure at the top shows both modes and the end state. Today, the policy has to travel inside what we already provide, and where that is depends on how we reach the model. • **Over the API**, we control the whole message. There is no vendor system prompt added to it; Anthropic's own release notes say its app system prompts ["do not apply to the Claude API"](https://docs.claude.com/en/release-notes/system-prompts). So the behaviour policy goes into our system prompt, and the vendor's checks on misuse still run, unseen. • **In the Claude apps and in Claude Code**, the vendor provides an explicit system prompt of its own, and we add to it: our instructions, a project's CLAUDE.md, or, in Claude Code, text [appended to the default system prompt](https://code.claude.com/docs/en/cli-reference). The behaviour policy goes there, after the vendor's. In both modes, today, the system prompt and our behaviour policy are almost pure hope. That is hope-driven development again: we really hope the model will keep them when it reads them. Anthropic is honest about this for Claude Code: CLAUDE.md files are treated ["as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead."](https://code.claude.com/docs/en/memory) And we do not know how sure the model is that it is keeping them. I have not seen a model report, rule by rule, how confident it is that it followed an instruction, and I have not seen a published figure for how often a system prompt or a policy is kept under pressure. That is research worth doing. My argument is that this should be a lot stronger than it is. The vendors already run checks outside the model where they care: Claude in Chrome has ["a safety classifier"](https://claude.com/blog/claude-in-chrome-generally-available) that validates each action before it is performed, and the platforms check for misuse and abuse in ways the user never sees. The behaviour policy deserves the same machinery, with one difference: the policy's rows should be controlled by us. The whole point is that a behaviour policy brings in business logic, which is specific to the application and to what we are doing, and which no vendor can write for us. ## A system prompt is a light behaviour policy {#system-prompt} There is a more evolved version of this, with more than one level. Claude itself has a behaviour policy: the rules in its system prompt and the ones its platforms enforce, from not typing passwords to asking before financial sites. It is just not written as one. And there is an argument that the system prompt should move to being a behaviour policy, because a system prompt is a light version of one already: it tells the agent how to behave. It is written as paragraphs for a model, when it could be written as rows a person can read, a platform can check, and a dispute can point to. So the layering I would want is simple to say. The vendor's policy, published, for what the platform does everywhere. The deployer's policy, on top, for what this agent in this business may do, with the business rules only the deployer can write. Each row marked with what enforces it, and each layer with an owner. That is the conversation I want to have with the vendors: not "add our text to your prompt", but what the policy should be, how it should exist, and who checks it, when we are giving an agent explicit guidance on how to behave across a whole business. 4 unchanged paragraphs, under Most agents already run a policy {#already}, What this does not claim {#limits} • **The confidence question is open.** I have not seen published figures for how often a model keeps a system prompt or a policy under pressure, or a model reporting its confidence rule by rule. 8 unchanged paragraphs, under Where this comes from {#sources} A voice memo of mine on 13 October 2026, expanding an idea from [The policy draws the liability line](../../the-policy-draws-the-liability-line.md) the same day, written by this site's agent in the voice of this site. The argument and the editorial responsibility are mine. Aviation: [Our World in Data](https://ourworldindata.org/grapher/fatal-airliner-accidents-per-million-flights) from the Aviation Safety Network; the Flight Safety Foundation's [2025 safety report](https://flightsafety.org/wp-content/uploads/2026/02/2025-Safety-Report-FINAL.pdf); [IATA](https://www.iata.org/en/pressroom/2026-releases/2026-03-09-01/), 9 March 2026. Payments: [15 U.S.C. 1643](https://www.law.cornell.edu/uscode/text/15/1643); the [Payment Services Regulations 2017, regulation 77](https://www.legislation.gov.uk/uksi/2017/752/regulation/77); [Visa on the 2015 liability shift](https://www.visa.co.id/dam/VCOM/global/partner-with-us/documents/visa-liability-shift.pdf); the [PCI Security Standards Council](https://www.pcisecuritystandards.org/about_us/); the PSR's [reimbursement dashboard](https://www.psr.org.uk/information-for-consumers/app-scams-reimbursement-dashboard) and [Frontier Economics' evaluation](https://www.frontier-economics.com/uk/en/news-and-insights/news/news-article-i22383-app-payment-scam-policies-reducing-fraud/); the US Senate Commerce Committee's [report on Target](https://www.commerce.senate.gov/services/files/24d3c229-4f2f-405d-b8db-a3a67f183883); PCWorld on [Verizon's 2014 breach report](https://www.pcworld.com/article/2146581/web-apps-and-pointofsale-were-leading-hacker-targets-in-2013-says-verizon.html). Fines: [The Record](https://therecord.media/eu-hands-meta-record-fine-over-data) on Meta's GDPR fine; the [European Commission](https://ec.europa.eu/commission/presscorner/detail/en/ip_25_1085), 23 April 2025. Code and data: the [NCSC](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection), 8 December 2025; Simon Willison, [The lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Version 1.1, the same evening, adds where the policy goes in each mode, why both modes are still hope, and the system prompt as a light behaviour policy, from a second memo of mine. System prompts: Anthropic's [release notes](https://docs.claude.com/en/release-notes/system-prompts), Claude Code's [CLI reference](https://code.claude.com/docs/en/cli-reference) and [memory documentation](https://code.claude.com/docs/en/memory), and the [Claude in Chrome announcement](https://claude.com/blog/claude-in-chrome-generally-available). Vendor policies: Anthropic's [Claude in Chrome safety page](https://support.claude.com/en/articles/12902428-using-claude-in-chrome-safely), [Claude Code's Chrome documentation](https://code.claude.com/docs/en/chrome) and [permissions](https://code.claude.com/docs/en/permissions). [all versions](../a-policy-beside-the-prompt.md) · [v1.2.0 →](v1.2.0.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/a-policy-beside-the-prompt/v1.1.0.html)*