RiskMandate v1.34.4
The business case · Mapping: the precondition for every other case

An Agent Behaviour Policy, by the risk it changes

The first case is our own product, so the method is tested on us before it is used on anybody else. An Agent Behaviour Policy changes no setting and blocks nothing. It writes down what one agent in one deployment can reach, what it was authorised to do, the gap, and what stands in the way. In the register that means two risks retired, one hidden risk named, and a handful reduced by instructions the agent is given, which the site calls expectations because they are hope, not control.

Disclosure: This is RiskMandate's own product, and the case is written by RiskMandate. Read it with that in mind; the method is the same one the other cases use, and the model is public.

The deployment: The typical deployment from the model, as it is before anybody has mapped the agent: asked what it could reach at full speed, the honest answer is that nobody knows.

The model: the RiskGraph Explorer's 49 facts, 49 risks and 10 roles, copied into this site with its provenance; the register below is computed, not written. How.

01 · What it does

In our own words, and nothing more.

  • Enumerates what the agent can reach, from the vendor's own pages or a run we are entitled to make, and writes it down as the grant. more
  • Records what the deployer authorised, as the mandate, and derives the gap between the two. more
  • Names, for each capability, what stands in the way: nothing, an expectation, a setting or a boundary, and who holds it. more
  • Ships the instructions an agent reads, AGENTS.md and SKILL.md, so the mandate is also written where the agent will see it. more
02 · The answers it changes

Same deployment, different answers.

The model asks sixteen questions about an agent deployment. A product’s effect is written as the answers it changes, and each change says what kind of change it is: a statement of what is true, an expectation the agent is asked to meet, a setting, or a boundary enforced by something the agent’s grant does not include.

The questionWithout itWith itHow, and who holds it
If it misbehaved at full speed, what could it reach?Don't knowCustomer-facingstates the answer, held by the deployer. The policy does not change what the agent can reach. It replaces don't know with the answer. For the typical deployment that answer is customer-facing, and saying so is exactly what puts a new risk on the register.
03 · The register, before and after

2 retired, 1 new, 22 unchanged.

Computed from the model for the deployment above: every risk that holds without it, and every risk that holds with it. A new entry is either one the change brought to light, where an answer replaced a don’t know, or a narrower risk in place of a wider one, where the answer moved from no to partly. Either way the register is more exact, and a register that grows because something was found is working.

2retired
1new
24 → 23entries on the register

Retired

RISK-8
The operator cannot state what the agent is entitled to reachoperational · SRE / platform on-call, Platform owner
RISK-17
The scope of the agent's access cannot be reviewedoperational · CISO

New

RISK-18
Customer-facing systems are reachable by the agentoperational · Customer-facing service owner, CISO, Chief Product Officer
04 · From the operator to the board

Who carries less, and who carries the same.

Each risk is assigned to the roles it belongs to, and each role reports to another until the board. The count beside each role is the entries it holds without the product and with it.

Operators

who run it, and are paged when it goes wrong
SRE / platform on-call10 → 9 −1retired RISK-8
Customer-facing service owner1 → 2 +1new RISK-18

Owners

who own what it may touch, and can say what happened
Platform owner4 → 3 −1retired RISK-8
CISO8 → 8retired RISK-17 · new RISK-18
DPO6 → 6

Executives

who answer for speed, product, cost and the whole
CTO3 → 3
Chief Product Officer3 → 4 +1new RISK-18
CFO0 → 0
CEO3 → 3

The board

who must be able to defend how it is run
Board4 → 4

At the board: the corporate register

Corporate risks have no facts of their own. They hold while any risk that leads into them holds, so a single product rarely retires one. What it changes is how many reasons the board is being given.

CORP-1
Regulatory exposure — the organisation may be operating outside obligations it is subject tostill holds · risks leading into it: 2 before, 2 after
CORP-2
Customer harm — customers may be affected by decisions or changes nobody madestill holds · risks leading into it: 2 before, 2 after
CORP-3
Operational resilience — the organisation may be unable to restore a service it depends onstill holds · risks leading into it: 1 before, 1 after
CORP-6
Loss of control — the organisation operates a system it may not be able to stop or explainstill holds · risks leading into it: 2 before, 2 after
05 · Reduced, not retired

What it asks the agent to do, and why that is hope.

Ask before any change to production, and say what the change is.an expectation · less likely: RISK-6 the production estate can be changed by an agent; RISK-15 the organisation acts through a system that acts without a person approving each action
Never edit more than five records in one run without asking; keep the prior state of anything you edit.an expectation · less likely: RISK-32 part of what the agent changes can only be partly recovered
Read personal data only for the task in hand, and never copy it out of the system it is in.an expectation · less likely: RISK-7 regulated data is readable by an agent; RISK-3 personal data is within reach of an automated actor

Each of these is a sentence the agent reads. It makes the behaviour less likely and bounds nothing: an agent can ignore it, misread it, or be told otherwise by something it reads. That is still better than silence, and it is why the other cases on this page exist. Hope is not a control.

What this does not claim

The limits of the case, stated by the case.

  • That any risk is smaller because the agent was told not to do something. Expectations are listed as reductions in likelihood, never as retirements.
  • That the register after the policy is acceptable. Acceptability is a decision a named person makes, for an interval.
  • Anything about corporate risks. They hold while an agent runs in production with personal data in reach, with or without a behaviour policy.
  • That the register is complete. It is one model, for one stated deployment. A different deployment changes the answers, and so the case.

Next. Every other case on this page starts from a question somebody has already answered truthfully. That answer is what a behaviour policy produces, which is why this case comes first.

The same method, for your product

Make the case in the register’s own terms.

If you build a security product for agents, the case for it can be written the same way: what it does in your own words, the answers it changes, and the register before and after. If a case here is wrong about you, tell us and it changes with a date.

All the casesWrite to us