claim candidate goes to: this-edition T town planner
A third input: a behaviour policy beside the system prompt and the prompt, which the vendor acknowledges, enforces where it can and answers for
An agent today gets a system prompt from its vendor and a prompt from us; it should also take an Agent Behaviour Policy, written to a published standard, which the vendor accepts as part of the deployment, enforces as far as the platform can see, reports every breach against the same day and, eventually, carries liability for the rows it accepted. The user answers for what is outside the policy and the vendor for what is inside it, which is a better model than the user being liable for everything because they clicked allow. Most agents already run a hidden policy of their own (Claude in Chrome will not type a password), and a system prompt is a light behaviour policy not written as one; the layering is the vendor's published policy, then the deployer's, with the business logic only the deployer can write.
Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).
Note. A proposal: the article says no vendor accepts a behaviour policy as an input today in this sense; Claude Code's permission rules and managed settings are the nearest thing and cover settings, not business rules. Liability per row is the end state, not the start; acknowledgement and breach reporting can come first.
Where it comes from
- A policy beside the prompt The idea: a policy beside the prompt; The user answers outside the policy, the vendor inside it; A system prompt is a light behaviour policy; Most agents already run a policy (newsroom)
What it answers in the 2018 book
- Threat Modeling answered outline, Security
Where it goes
Chapter Controlling your agent: RiskMandate, part Build it without a server (drafting); topic Controlling your agent: mandate, reach and hope versus enforcement.
Other ideas proposed for the same chapter: Mandate, reach and the gap: hope versus enforcement, Code is a liability; the future is the smallest code that does the job, Learning to hack is still how you learn how things work: draw the line where the attacker is, The secret goes from the drop into the tool, never into the chat, Security experience is what lets you ship with known gaps: list them, match them to the reader, say what would change the call, The agent behaviour policy is the due diligence document: a buyer reads the blast radius off it, and its absence says the most, A vault per conversation and per job: a leaked key exposes one small thing, not an inbox, The desktop is the barrier, not the model: prompt injection is not solved, so the box has to hold, Reach is a computed value, and new capability lands as excess, never as new authority, Who can pull the plug: an agent that cannot be stopped is riskier than one that can, Models do not separate code from data, so a rule in the prompt can be argued with by an email, Aviation and payments got safe when the rule, the liability and the business model pointed the same way, Zoom into an agent's behaviour policy and you find the business logic, which only the business can write, Software was the law: the rule the screen enforced by omission is no longer enforced once an agent calls the API, Every rule lands in one of three states: backed by a control, governed by an accepted risk, or resting on hope, Write down what your agent can reach in twenty minutes: list its tools, say what you wanted it for, write the gap.
Node idea:a-policy-beside-the-prompt in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.