sgit newsroom v0.1.29 · snapshot 2026-09-24

Reading room · riskmandate.ai

On this page

Reading room / riskmandate.ai · raw text · live ↗

From riskmandate.ai, the page as fetched on 2026-09-24 · open the live page ↗Everything on this sheet is the source site's own text; the newsroom's chrome is outside it.

RiskMandate — the business case for Agent Behaviour Policy

Agent Behaviour Policy (RiskMandate), by the risk it changes: the register for a stated agent deployment without it and with it, computed from a public model, from the operator to the board.

Source: https://riskmandate.ai/business-case-riskmandate-abp.html↗


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↗.

In our own words, and nothing more.

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.

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.

Retired

New

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

Owners

Executives

The board

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.

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

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 ↗.

The limits of the case, stated by 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.

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.