RiskMandate: the X-ray deck
The full X-ray of RiskMandate · keys ← → · F fullscreen · A all slides. The plain-text version is this page's markdown twin (index.md).
X-rayed by RiskMandate
RiskMandate
Give agents access. Not free rein: a written record of what one AI agent can reach, what you authorised, and the gap.
Sources read on 2026-11-07 · web-summit.sgit.ai/xray/riskmandate
What it does
RiskMandate
RiskMandate writes an Agent Behaviour Policy for one AI agent in one deployment: everything the agent can reach, what the business authorised it to do, the gap between the two, and what stands in the way of each thing, with no score. Its llms.txt says it measures what agents can actually reach, evidences the controls that contain them, prices the exposure, and produces that record for an underwriter. It is read-only and never in the request path: it defines the mandate and measures the gap, and enforcement is left to the deployer's own controls or to SHarness, the open-source harness it maintains.
Sources: s1, s2, s8
Its AI agents
What acts on its own
RiskMandate Publisher (RiskMandate's own agent)The one agent that reads RiskMandate's private stories vault and writes the public riskmandate.ai site. It runs as Claude Code on the web in a managed container with the site repository attached and an egress proxy above it, and RiskMandate publishes its Agent Behaviour Policy.
- Reads the stories vault and the site repository
- Checks what the design studio delivers against the site's rules
- Publishes what the lead has accepted as a release on dev, which deploys the live site
- Copies what is live back into the vault and keeps the board
RiskMandate Design Studio (RiskMandate's own agent)Writes storyboards, draws them with image models, proposes cast, and delivers into its own folders of the private vault; it never publishes.
- Writes storyboards
- Draws them with image models
- Delivers into its own folders of the private vault
The riskmandate.ai site agent and its mailbox (RiskMandate's own agent)One identity that is a monitored mailbox when written to as an address and a write-only lane on an encrypted vault when written to as an agent. The site says riskmandate.ai is kept by one person and their agents, and that the mailbox account has six roles behind it.
- Reads the inbox on a schedule and writes a tagged list of what needs to happen
- Labels, threads, files and drafts replies
- Sends only from drafts the mailbox role prepared, with outbound delivery restricted by an admin rule
- Accepts signed, encrypted agent mail from allow-listed domains; unsigned or off-list messages are dropped unread
Use case · The Caretaker (example from RiskMandate's stories)
An assistant on one mailbox: asked for one message, granted the whole mailbox
Reach
- Every message in the mailbox: the narrowest Gmail scope that reads one message body reads every message, with no scope that filters by sender, label or date data
- Sending email as the person, to anyone; the consent screen RiskMandate quotes grants "Read, compose and send emails from your Gmail account", and sent mail cannot be recalled outside
- Changing the mailbox itself: archiving and reorganising threads around the one that was asked for system
- Other people's correspondence in the mailbox: clients and counterparties who never agreed to the connection (RiskMandate calls this material "mixed") people
- Writing and saving draft replies in the person's mailbox data
Mandate (illustrative)
- Illustrative: find the message the person asks for, and read what the task is about
- Illustrative: draft replies for the person to read; never send
- Illustrative: leave the rest of the mailbox where the person left it
Gap
- Send is in the grant and not in the mandate; on RiskMandate's Gmail connector story, a setting the account can flip is all that stands in the way
- Reading and reorganising the whole mailbox, including third parties' mail, when the mandate was one message
Use case · Sales agent in a CRM (example from the RiskMandate homepage)
A sales agent in the CRM, and the export nobody approved
Reach
- Customer contact records, and exporting them in bulk (the homepage examples ask for 2,400 and 12,400 contacts) data
- Deleting an opportunity system
- Editing a closed-won deal money
- Logging a call or an email against an account data
- Sending customer data outside the company (the homepage's sample policy line: "Staff must not use AI tools to send confidential data outside the company") outside
Mandate (illustrative)
- Illustrative: log calls and emails against the accounts it works on
- Illustrative: export customer contacts only with a manager's approval, and not more than 500 records at a time
- Illustrative: never delete an opportunity or change a closed deal
Gap
- Bulk export of customer contacts, and sending them outside the company, is in the grant beyond the approved limit
- Deleting opportunities and editing closed-won deals are in the grant and outside the mandate
Use case · RiskMandate Publisher (RiskMandate's own agent)
RiskMandate's own Publisher: the site, the vault and the keys in the transcript
Reach
- Every file in the attached riskmandate.ai repository, read and write, with nothing bounding which files a commit touches code
- Pushing dev, which is the live site under the name riskmandate.ai within minutes; the record calls this not undoable outside
- Credentials on the host: the session's signing key, and the stories vault key and push token the lead pasted into the chat data
- Minting a new vault key under the account with the account token it holds system
- The hosts the platform's egress proxy allows, such as riskmandate.ai, the vault host and the code host outside
- Its own session transcript: earlier tool outputs, and the key and token the lead pasted data
Mandate (illustrative)
- As RiskMandate published it for this agent: build and publish riskmandate.ai, pushing dev only through the merge workflow after the check passes
- As published: never hold a secret in a file; reading credentials beyond the session's own is refused
- As published: never mint a vault, widen a token or ask for a broader one
Gap
- Reading the vault key and token, and minting a vault, are refused by the mandate with nothing in the way (the record counts 4 in excess, 3 unbounded)
- Reading its own transcript, which holds the pasted key and token, is in the grant and unstated in the mandate
The simulation · An assistant on one mailbox: asked for one message, granted the whole mailbox
Each action, placed against the mandate
- Asks the assistant to find last month's invoice in the mandate
- Searches the mailbox and finds the invoice in the mandate
- Reads other threads, including client correspondence, while it is there in the gap
The record: The record shows read access to the whole mailbox as grant, one message as mandate, and the difference as gap, with the material marked as other people's. - Archives everything else so the inbox reads zero in the gap
The record: The record shows changing the mailbox as a gap row: in the grant, not in the mandate, with nothing but the request in the way. - Drafts a reply to the invoice thread in the mandate
- Judges the draft ready and sends it in the gap
The record: The record shows send as a gap row whose barrier is a setting the account can flip, and marks it as an action that cannot be undone. The gap is made visible for an owner to accept, fund or fix; RiskMandate does not stop the send.
What RiskMandate gives
RiskMandate is never in the request path: read-only by design.
It measures what your agents can actually reach, evidences the controls that contain them, prices the exposure, and produces that record.
riskmandate.ai/llms.txt
Sources
Every fact, with its source and the date read
- s1 RiskMandate: Give agents access. Not free rein. own-site, read 2026-11-07
- s2 RiskMandate: The insurability layer for agentic AI (llms.txt) own-site, read 2026-11-07
- s3 RiskMandate: about, the company, the two founders, and the investor deck own-site, read 2026-11-07
- s4 RiskMandate: Agents, the contact file, the mailbox and the lane own-site, read 2026-11-07
- s5 RiskMandate: The team, who does what, and what stands in the way own-site, read 2026-11-07
- s6 RiskMandate: RiskMandate Publisher, its Agent Behaviour Policy own-site, read 2026-11-07
- s7 RiskMandate Publisher: behaviour policy data (publisher.json) own-site, read 2026-11-07
- s8 RiskMandate: Agent Behaviour Policies, one vault per application own-site, read 2026-11-07
- s9 RiskMandate: How it works, from a prompt to a graph with provenance own-site, read 2026-11-07
- s10 RiskMandate: Know the risk. Name the owner. Own the mandate. own-site, read 2026-11-07
And 12 more on the X-ray page.
The questions we would ask
We have not asked them yet
- How many early-access members have run the prompts and corrected a mandate, and how many policies have been sold at the corrected or reviewed levels?
- Has an underwriter accepted an Agent Behaviour Policy as evidence at a renewal, and how will the Insurability Index, now in design, be weighted?
- When a vendor changes a connector's scope in a release, how soon is a published vault's grant re-measured, and how is the holder of a corrected vault told?
- When will the SHarness launcher that holds the agent itself move from design to something that runs?
- For your own Publisher, have the branch rule at the code host and a token scoped to one vault been put in place since 26 September 2026?
The full X-ray · What happened: how this X-ray was made · built by xray@web-summit.dinis