You know what you asked for. You do not know what it can do.
An Agent Behaviour Policy is a written description, for one agent in one deployment, of everything it can do, what it was authorised to do, the difference between the two, and what actually stands in the way. It is derived from the deployment rather than copied from a template. It describes and it does not judge, so it carries no score.
The gap
You know what you asked for. Draft the reply, fix the build, summarise the ticket, book the travel. That is the mandate, and it is usually clear, whether or not anybody wrote it down.
You do not know what it can do. The agent runs with an account, on a machine, inside a container or on a desktop, with credentials and network access and a set of tools. Everything those permit is the grant. It is almost never enumerated, and when it is, it is larger than the person who deployed the agent expected.
The four objects
An ABP is not a single list. It is four objects, and the order they are produced in matters.
| Object | What it is | How it is obtained |
|---|---|---|
| The mandate | What the agent is authorised and expected to do | Elicited. In minutes, because the deployer already knows 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 | Computed. Never stored, because the deployment changes |
| The barrier | What stands between the agent and each capability | Recorded, per capability, from one of four kinds |
A grant on its own is an inventory, and nobody acts on an inventory. Your agent can do three hundred and forty things is a shrug. Your agent can do three hundred and forty things and you authorised twelve is a finding. The model, in full.
Only one kind of thing is actually in the way
| 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 |
One setting, two documents
The clearest way to see what an ABP does is to change one setting and watch the document change. A coding agent on a developer's own machine, profiled twice: once with confirmations 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) |
1 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 setting the agent's own account could change, which is the third row and not the fourth. The ABP is about the deployment, not the product, and the pair says it in a way no paragraph can: confirmations on and confirmations off.
It describes and it does not judge
The same ABP 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. Risk is a function of the ABP, the assets, the consequences and the date, and the ABP is the one input that does not move.
What is here
What an ABP is
The foundation document: the definition, the four objects, the barrier, one worked example with published numbers, and the questions we would like answered.
The model
The 23 capability primitives, the four barriers, the three undo classes, the graph rules and the schema.
Five worked examples
From the smallest grant in the set to a service account that outlives the turn. Derived from the data, with the delta computed on the page.
The data
The published vocabulary as JSON, at stable addresses with cross origin access, with the source bytes it was promoted from.
The docs
Every reference document behind this site, rendered, each one click from its source bytes.
Where a score lives
The ABP is the input. The risk work above it knows the assets and the consequences, and a named professional signs.
What an ABP is not
- Not an acceptable use policy. That governs a person's use of a system. An ABP governs what an agent can and may do.
- Not a risk assessment. It has no assets in it and no consequences. It is the input to one.
- Not a compliance assessment, a certification, an audit or a security review of anything or anybody.
- Not a guardrail. It is what guardrails are compiled from. The barrier column says which prohibitions are guardrails already and which are sentences.
- Not a claim about any product. The capability rows come from published documentation and published measurement, with the source, the date and the measured ratio stated, and no adjective attached to any of them.
- Not a template. It is derived from one deployment, and a template cannot know what your agent can do.
This site is the library. It is free, and it stays free
The argument, the model, the examples and the data are published here. There is no checkout on this site and there will not be one. The data files are the shared facts and they live in the repository so that people can propose changes to them, with evidence attached.
Propose a change · The repository · Everything on this site, in one file
sha256:d6d4ba40f1fb1f93f66. The source bytes.