RiskMandate — articles

One argument at a time, from the record: what a deployment actually does, the screen or page it was read from, and where the accountability lands. Every claim sourced and dated; nothing tested on anybody else's system; nothing scored.

Source: https://riskmandate.ai/articles.html↗

One argument at a time, from the record.

Each of these takes one thing a deployment actually does, shows the screen or the page it was read from, and follows it to where the accountability lands. Every claim carries a source and a date. Nothing is tested on anybody else's system, nothing is scored, and where a vendor's own pages disagree the article says so rather than settling it.

Written so far.

Who owns what in AI. And how accountability holds on the way up.↗

A reply to an infographic on LinkedIn that maps thirteen roles to what each owns in AI and what that protects. Every company will redraw a map like it, and so it should. The map runs sideways, and accountability runs upwards: its middle column says where a risk lands, and the organisation chart says where it goes when nobody decides. One invented agent worked from the nine rows of its behaviour policy to the board: the same exposure in thirteen voices, seven rules, six weeks, and the model in enough detail to build. Three figures are drawn by the page from its own data, and one can be played: connect the assistant and watch the risks travel up, add a boundary and watch them end.

A deleted meeting comes back. An edited one does not.↗

Google Calendar keeps a deleted event in a trash for 30 days and documents no way for a user to restore an edited one. An agent allowed to edit can leave fifty meetings that look right and are wrong, with nothing to restore them from, which makes edit the dangerous permission and delete the recoverable one. What Google keeps after each action, in its own words, for personal and Workspace accounts; three places where Google's pages disagree, published unresolved; and the draft Calendar rows of a behaviour policy, with recovery beside each.

The pilot worked. Then somebody asked what else it could do.↗

Most generative AI and agent pilots never reach production, and some that do are switched off again. The hypothesis: the business compares what the agent was meant to do with what it can do, at machine speed and on somebody's authority, and declines to sign for the difference. Fourteen surveys and forecasts with the causes each one names, seven cases where what a system said or did became the company's, five variables the lethal trifecta leaves out, and a plain account of what the data does not show. Then the fix: limits written in business units at design time, each beside what enforces it.

In this session, the agent holds the union of everything it has ever been allowed to do.↗

A session that only reads still holds everything you ever allowed. Open a new chat, ask the agent to read your inbox, and nothing in that sentence authorises sending mail or changing labels — but a conversation is not an authorisation boundary. The session runs on the credential you granted months ago and the approvals you clicked in other conversations for other reasons. How the union forms at three layers, in each vendor's own documented words; the six questions a deployer would ask and the four the help page leaves silent; why “don't press Always allow” does not survive the mechanics; and the one lever a deployer still has when the credential has no per-session setting to offer.

Somebody will ask what your agent can do. You need an answer they can check.↗

An introduction to the Agent Behaviour Policy: the three answers people give today and why none of them survives contact; the four objects and the verb attached to each — the mandate elicited, the grant measured, the delta derived, the barrier recorded; the twenty-three primitives that let two policies be read side by side; the four kinds of barrier and the one test that separates a control from a rule in prose. Then one real deployment worked all the way through, with every number traceable to the record it came from.

An approval prompt is not a human in the loop.↗

A connector asks Claude wants to use Add labels to message from Gmail and offers Deny, Always allow and Allow once. It does not say which label, on which message, in which thread, or whether the agent was asked by the person or by an email it had just read. One of the three buttons removes the question permanently, and it is pressed by the account the prompt exists to protect. What the screen carries, what Google had already authorised before it appeared, and why the person clicking it ends up accountable for a decision they were not given enough to make.

Being written, in no fixed order.

Listed so the queue is visible rather than implied. None of these exists yet; each one already has its record behind it in a behaviour policy, which is the only reason it is on the list.

A barrier somebody can withdraw on a Tuesday

Attachment content is out of reach in this deployment because a client ships no tool for it — while the credential authorises the bytes. A block a vendor holds as a product decision moves in a release, with no consent screen and no notice. What that means for anyone relying on it.

The consent screen you cannot remember

Three lines, each with its own tick box, all pre-ticked under Select all. What those three actually authorise, in Google's own words, against what the product then offers — and the distance between the two.

Reading a message is not authorisation to forward it

The mail in an inbox was sent to one person under one expectation. An agent that may read it may also forward it, and the authorisation the sender gave does not stretch that far. Whose rights are in play, and what the record can honestly say about it.

The agent's mail is your mail

A message sent through the connector carries no header naming the client. To the recipient it is the account holder's. What that does to attribution, measured on the sending side.

The mailbox is a credential store

Password resets, one-time codes, invitations and recovery mail arrive by email, and reading messages reads those. A capability with no separate permission behind it, and no tool on either vendor's page that separates them.

The rules, stated so they can be held against us.

• Nothing is tested on somebody else's system. A claim comes from a vendor's own published page, quoted and dated, or from a system we are entitled to run. Where those two disagree, the disagreement is published unresolved.
• No verdict on a named company. Facts, dates and sources. Screens are quoted rather than characterised. The judgment these pages make is about a mechanism, using a test that is published and applied the same way everywhere.
• Nothing is scored. No rating, no traffic light, no strong-or-weak. What a barrier is worth depends on the deployment it sits in, which is exactly why the barrier is described instead: who holds it, what it rests on, whether it moves without you, and what would take it away.
• What was not done is stated beside what was. If a question is open, it is listed as open, with how it would be settled. A number nobody has measured does not appear here because it sounds right.
• Each article says which deployment shape it is about and links to that shape's behaviour policy↗, so every claim can be checked against the record it came from.

Sixteen deployments, described.

For one agent in one deployment: everything it can do, what it was authorised to do, the gap between the two, and who holds each thing standing in the way. Read them with their keys, or have one corrected for your deployment.