An Agent Behaviour Policy is a written description, for one agent in one deployment, of everything it can do, what you authorised it to do, the gap between the two, and what actually stands in the way. It is derived from your deployment rather than copied from a template. It describes and it does not judge, so it carries no score.
A behaviour policy is not a single list. The mandate is cheap, because you already know it. The grant is the work. The delta falls out of the two and is never written by hand.
| Object | What it is | How it is obtained |
|---|---|---|
| The mandate | What the agent is authorised and expected to do | Elicited. In minutes, because you already know it |
| The grant | Everything the agent can do | Measured. From the deployment shape, the account and the credentials |
| The delta | Excess where it can and you did not ask; shortfall where you asked and it cannot | Derived. Recomputed whenever the grant or the mandate moves, stored with the versions of both, never edited |
| The barrier | What stands between the agent and each capability | Recorded per capability, from one of four kinds |
“Your agent can do 340 things.”
A shrug. Nobody acts on an inventory, and the length of the list looks like a maintenance problem rather than a finding.
“Your agent can do 340 things and you authorised 12.”
The mandate is the edge that gives the enumeration a shape. It is the cheapest object to capture and the one that makes the other three mean something.
For every capability in the grant, a behaviour policy records what stands between the agent and it. There are four kinds, and three of them bound nothing. That is not an opinion — it follows from what each one is.
| Barrier | What stands in the way | Is it a control | |
|---|---|---|---|
| ● | none | nothing in the way | no |
| ◉ | expectation | a rule in prose, enforced by nobody | no |
| ◐ | setting | a switch the agent's own account can flip | no |
| ○ | boundary | enforced above the grant, out of the agent's reach | yes |
A control bounds a grant only if it is enforced by something the grant does not include.
Read the third and fourth rows together and the test falls out of them. A setting the agent's own account could change is not a control, because the grant includes the ability to remove the bound. A boundary enforced above it, that it cannot reach, is a control — because it does not.
Every prohibition we render carries its barrier. One shown without it is a claim we cannot support, and it manufactures assurance. For most deployments today the honest answer is the second row. · The barrier, in full · as JSON
The clearest way to see what a behaviour policy does is to change one setting and watch the document change. A coding agent on a developer's own machine, profiled twice — once with confirmation prompts enabled, once with them disabled. Same product, same machine, same account.
| Confirmations on | Confirmations off | |
|---|---|---|
| Grant | 16 | 16 |
| Mandate | 5 | 5 |
| Excess | 12 | 12 |
| Unbounded excess | 12 | 12 |
Barrier on execute.process.host | setting — not a control | none — not a control |
One barrier moved, and not one number did.
The confirmation prompt was the only thing standing between an authorised capability and the whole of the machine — and it was a switch the agent's own account could flip, which is the third row and not the fourth. A behaviour policy is about the deployment, not about the product.
Both documents are derived from published data rather than authored, and each states which of its rows were measured. · confirmations on · confirmations off · all five examples
The same behaviour policy is dangerous in one deployment and harmless in another, and nothing about the document changed. The most permissive grant imaginable, running where there are no assets and nothing reachable, is a low risk. The same grant with a production database attached tomorrow is a high one.
A policy cannot be dangerous. A deployment can.
So there is no rating on a behaviour policy, no traffic light and no risk level — not on this page, not in the data. Risk is a function of the policy, the assets, the consequences and the date, and the policy is the one input that does not move.
A label describes a substance and never says this is safe for you. A patient record supplies the context. A prescribing decision combines the two, and a named professional signs it and carries the responsibility. Three things, and only the third can hold a number.
What the agent can do, what you authorised, the gap, and what is in the way. Context-free, so it is the same document wherever the agent runs.
A read-only model of the environment the agent is actually in: the assets, the tools, the data, what is connected to what. This is where the grant stops being a deployment shape and becomes yours.
The two combined, dated, with a named owner and an expiry — so the decision comes back. This is what RiskMandate is, and it is the only rung with a score on it.
The people who sell do not sign, which is why the label and the prescription are separate products rather than two sections of one.
Unbounded excess is the only number on a behaviour policy that anybody can move. Every real control shifts one capability out of the agent's reach and into the fourth row, and the number falls.
If you sell a control and want the count for your product against the five published deployment shapes, that is what the partner conversation is.
You do not need to give us access to anything. A draft behaviour policy is derived from a deployment shape — which agent, running where, with which class of credentials — and handed to you. Correcting it is how you state your mandate, and the correction is usually upward.