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 one of the three 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.
The four objects are what you read. What they are made of is a set of behaviour nodes and the edges between them, which is why the same policy can be read by four different people without being written four times. Half of this is running today and half is drawn; both are marked below, and the direction brief behind it is published in full.
The capability vocabulary is a fixed set of ids, pinned at abp.sgit.ai and shared by every vault. execute.process.host is remote code execution as the account; delete.file.host is data deletion; send.endpoint.world is unrestricted network reach. They are ids rather than prose, so they can be linked, counted and compared across policies.
A grant row is an edge from this deployment to a behaviour node, carrying the door it goes through, the evidence tier it is known at, how reversible it is, and the barrier that stands in the way. The same behaviour is often barred through one door and open through another, which is a property of the path rather than of the behaviour.
Each vault carries several mandates over one grant: the same behaviours, filtered for a different purpose. That is the projection mechanism working, one axis at a time, and it is what the stakeholder views are built from.
MAP-A-GRANT.md travels with every policy, so the document you read can be regenerated from the data by whoever holds the keys. A projection nobody can reproduce is a claim; one you can re-run is a method.
Operator, security, leadership and insurance read different things off one record, and the plan is for each view to be content in the vault rather than a page on this site. The reading app opens on one view for everybody today, and the register says so.
A behaviour node is a good centre: the attack techniques that use it, the standards that name it, the obligations it touches. With those edges in place, which policies can delete data becomes a query rather than a reading exercise, and every behaviour gets its own page listing the policies and their barriers.
Why this matters commercially, stated plainly: a graph is what lets one record serve four audiences and connect to whatever standard somebody already reports against. If that is the part you want to talk about, say so — it is the half of the model that is still being built, and the people who ask about it tend to be the people who have already tried to do it themselves.
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.