RiskMandate v1.15.0
Behaviour-policy vaults · One per target application. Every vault here is read live in your browser with a published read key. The model · How the first one was built
Agent Behaviour Policies, one per application

Which agent do you run?

Pick the application closest to yours. Each is a vault: a measured grant for that application, a starting mandate written to be corrected, the delta between them, and the files you hand the agent — with its own app, its own history, and a read key you can hand to anyone who asks how you govern it. The ones below are templates: free, public, derived from published data, and never scored. Yours is one of these with the mandate corrected, a name on the licence, and no public key.

Claude Code on the web →
Available now · 15

One vault per application. Derived, never authored, and the numbers are live.

Every tile is a deployment shape published at abp.sgit.ai and built into a vault by one command. The counts are read from the vault as you look: grant, wanted, excess, unbounded. Where a vault cannot be reached the tile says so and falls back to the copy served from this site.

Claude Code on the web

A managed, ephemeral container with one repository attached and an egress proxy above it. The shape this site is maintained from; 13 of 20 rows measured on the thing itself.

15 it can do · 6 wanted · 9 not · 7 unbounded
+

Claude Code on your machine

The coding agent on a developer's own machine with confirmation prompts enabled. Read this one beside the confirmations-off shape: one setting moves one barrier and not one number changes.

16 it can do · 5 wanted · 12 not · 12 unbounded
+

Claude Code, confirmations off

The same agent, the same machine, the same account, with the confirmation prompt switched off. The prompt was the only thing between an authorised capability and the whole machine, and it was a switch the agent's account could flip.

16 it can do · 5 wanted · 12 not · 12 unbounded
+

Claude Desktop

The desktop app with local tools on: files, processes and the network of the machine it sits on. Ten capabilities, three wanted, eight with nothing real in the way.

10 it can do · 3 wanted · 8 not · 8 unbounded
+

Claude in the browser, connectors on

Chat with connectors enabled: the tenant's accounts are in reach through whatever was connected. The two excess rows here both sit behind a boundary, which is the exception in this directory.

5 it can do · 3 wanted · 2 not · 0 unbounded
+

ChatGPT in the browser

The smallest grant in the set: one capability, one wanted, no excess. The baseline every other shape is measured against, and the proof that a template can be empty and still be right.

1 it can do · 1 wanted · 0 not · 0 unbounded
+

A browser extension

Other people's data, and the mandate nobody wrote down. Three capabilities, all three irreversible; the shortest policy in the directory and not the mildest.

3 it can do · 1 wanted · 2 not · 2 unbounded
+

GitHub Actions

A hosted runner under a service account: persistence, and reach beyond the turn. Eight of eight rows measured, the only fully measured shape besides the web container.

8 it can do · 5 wanted · 4 not · 3 unbounded
+

A scheduled job

A job that outlives the person who made it, running as a service account nobody logs in as. Seven capabilities, four wanted, four with nothing in the way.

7 it can do · 4 wanted · 4 not · 4 unbounded
+

Google Workspace MCP servers

Gmail, Drive, Docs, Sheets, Slides, Calendar and Chat, one server each. The page advertises drafting mail and scheduling meetings; the scopes it asks for send mail and cannot touch a calendar.

6 it can do · 2 wanted · 4 not · 1 unbounded · 4 open questions
+

Gmail, read-only scope

The narrowest scope that reads one message reads every message. Lab 03 asked the model site for this shape first; here it is, read from Google's scope page.

4 it can do · 1 wanted · 3 not · 2 unbounded · 3 open questions
+

Google Drive, read-only scope

The default corpus is "files owned by or shared to the user": everything anybody ever shared, on day one, without anyone choosing it.

3 it can do · 1 wanted · 2 not · 1 unbounded · 3 open questions
+

Microsoft 365 connector (Claude)

Delegated permissions, consented once by a Global Administrator. Shared mailboxes are in scope; site-specific narrowing is unsupported because the search is tenant-wide; and the page that says "read-only access" also lists the tools that send mail as the user.

5 it can do · 2 wanted · 3 not · 1 unbounded · 4 open questions
+

Dropbox MCP server

Eight scopes, two of them write and two of them sharing, and no folder-scoped variant. It reads, creates, moves, deletes and makes shared links; the page says files are not deleted permanently and that recovery depends on your plan.

5 it can do · 1 wanted · 4 not · 0 unbounded · 4 open questions
+

n8n, owner API key

The first grant here measured on a live instance, by an early beta user's agent: full control of every automation, an outbound node with no restriction on target, every account visible, and credential metadata open through one door and shut through another.

8 it can do · 4 wanted · 4 not · 4 unbounded · 4 open questions
+
Not yet researched · 5

The next connectors, and what each one waits for.

A vault is built from a measured or documented grant, never typed. The four connector shapes Lab 03 asked the model site for are built above, ahead of the model site, from the vendors' own pages read and quoted on a date — and each carries the questions those pages could not settle in its RESEARCH-NEEDED.md, written to be handed to an agent. These are the connectors whose pages have not been read yet. Nothing here is invented to fill a grid.

Claude's Google Workspace connector

Gmail, Calendar and Drive from inside Claude. The connector's scope list has not been read yet; the Google pages behind it have.

not yet researched — next in the queue

An assistant connected to Slack

Channels are mostly other people's writing, and a bot token reaches every channel it is in.

not yet researched

An assistant connected to GitHub

A fine-grained token can be scoped to a repository; an OAuth app cannot, and most connectors are OAuth apps.

not yet researched

An assistant connected to Notion

An integration is added page by page, which is the one connector model with a floor. Whether the assistant's connector uses it is the question.

not yet researched

An assistant connected to Salesforce

A CRM is entirely third-party material by construction.

not yet researched
  • Mandates are per application, not per agent — to begin with. The mandate in a template is really the mandate for a resource: a repository attached to a coding agent, a mailbox connected to an assistant. That is what makes the library reusable, and why the directory is organised by application rather than by model.
  • A documented grant is not a measured one. The connector vaults stand at the documented tier: every row quotes a vendor page and names its date, nothing was tested, and the rows a page could not settle are counted on the tile as open questions. A measured row needs a system we are entitled to run, and probing somebody else's is out of bounds here with no research exemption.
  • Run something that is not here? The generator takes a grant and a mandate and does the rest. Ask the agent to check its own grant with the block at the end of any GRANT.md, and send us what it finds: that is how a new application gets its row.
From simple to complete

The same vault, at four altitudes.

Not every reader needs the tables. Each vault renders the same files at four levels of detail, and every level is derived from the same bytes — so the tile above and the row in an underwriter's spreadsheet cannot disagree.

01 · THE CARD

Four counts, no score

Grant, wanted, excess, unbounded — and the excess split by barrier. The shape of the Index card on the home page, with the one number that is not allowed removed.

02 · THE TABLES

Every row, with its barrier

The grant irreversible-first, the delta in its three lists, the licence's conditions next to what enforces each. On each vault's page, rendered live.

03 · THE APP

The vault's own interface

Opens on Start here: what this is, where the pieces go, what we want the agent to do beside what we do not, and three ways to hand it over — copy-and-paste, a zip, a PDF. Embedded on each vault's page in a sandboxed frame.

04 · THE FILES

The bytes themselves

Markdown for people, JSON for machines, the pinned vocabulary, the history, and the two files you hand the agent. Cloned with one command from the read key.

How this page reads a vault

Ciphertext in, decrypted here, and always the current commit.

The vault API answers plain cross-origin GETs with no auth header, because what it returns is ciphertext under a key the server has never held. This page derives each vault's HEAD address from its read key, fetches the ref, the commit, the trees and the blobs it needs, and decrypts them in your browser. A push to a vault is live on the next page load — no rebuild of this site, no redeploy.

  • The viewer is the site's. The data is the vault's. Every string from a vault is rendered as text, never as markup. A vault's app runs only inside a sandboxed frame with an opaque origin, served its reads over a message channel. A vault can change what is shown; it can never change what the page does.
  • Immutable objects are cached; the ref never is. A stale ref would render an older commit from perfectly valid ciphertext and nothing would error, so the page fetches it fresh every time.
  • The read keys are printed, on purpose. Each is derived one-way from its vault's write key and cannot be turned back into it. Anyone can clone a vault with it and check what its page says against what is there. No write credential is anywhere in this site, and a test fails the build if one lands.
  • The reader is copied, not fetched. It is sgit.ai's house reader, about ninety lines, in each page's own source — the brief that documents it says to copy it rather than load it across origins at runtime.

The mechanism is written up at sgit.ai — reading one file out of a vault, the rules for a site page at reading a vault from a site page. The template, the generator and the catalogue behind every vault here are in this site's repository; Lab 07 is the record of the first one.

Behaviour-policy vaults

Pick the application closest to yours. Then correct the mandate.

Everything else in the vault is derived. The correction is the elicitation, and the corrected vault — with a name on the licence and no public key — is what is sold.