Home / Briefs / The RiskMandate sandbox

The RiskMandate sandbox: three twins, one policy, a real model, and the question of whose key

A project brief from the sgit.ai site team, for the RiskMandate.ai team and the SG/Send teams. Status: draft for the founders to review. Written 2 October 2026 from a voice memo. Nothing in it has been built as a whole; most of its parts have, and the brief says which.

What this is, in one paragraph

A place where an Agent Behaviour Policy can be tested rather than read. You pick a scenario, say an inbox agent asked to clear a backlog, and the sandbox runs a real model against a simulated inbox, through a simulated connector, under a simulated permission prompt. Nothing is live: no account, no Gmail, no OAuth grant. The run produces a footprint, every tool call with its result. Then you run it again with a policy in place, and the two footprints sit side by side. The difference is what the policy bought, and the gap rows the agent reached, shaded by blast radius, are what it did not. The sandbox is also where a policy gets written, because the fastest way to write one is to watch the agent without it first.

Why write it here first

Because the parts are here. The vault LLM bridge, the connector twin, the chat panel with tools, the one-prompt workflow, the vault-app proofs of concept, the synthetic users run, the provider reports, and now footprint and blast radius: every one of them is a published page or a published vault on this site or a sibling, with a read key and an audit. The RiskMandate team has the policy and the sixteen published examples. A brief written from here can point at a running thing for almost every box in the picture and say what is missing, which is the assembly. Written from the RiskMandate side it would have to describe the vault machinery second-hand. So: the brief here, the product there, and the sandbox vault itself published on both.

Three names, and which to use

• Sandbox for the place. It says safe to break, which is the point. "Playground" is what the model vendors call a prompt box, and "eval" is a measurement, not a room.
• Evals for the scenarios. Each one is a seeded inbox, a task, an optional policy, and a model, and it produces a footprint that can be scored. The word is already what the industry uses for exactly this, and it says the result is a number, not a feeling.
• Twins for the simulated systems, as in the connector twin. A twin behaves like the real thing at the boundary and records everything that crosses it.

The three twins, and why three

The memo's instinct that an inbox needs three twins, not one, is the architectural centre of this. Each layer adds a different kind of constraint, and a policy has to be tested against all of them.

The agent sits on top with a real model, chosen per run. Its calls go down through the three twins and the results and errors come back up. The policy, when on, is in the agent's context and, where the harness supports it, enforced at twin 3. When off, the agent has the reach and nothing else.

What a run shows

1. The footprint. Every tool call, its arguments, its result or error, and the twin that answered it. Written to the sandbox vault, so it is signed, versioned and readable with a read key.
2. With and without. The same seed, the same task, the same model, policy on and policy off, side by side. The gap rows the agent reached without the policy, and whether it still reached them with it.
3. Blast radius per row. Each row the agent touched, shaded by what it would have cost against the seeded inbox at that moment: a draft is nothing, a send as the owner is the business, a permanent delete is hatched because there is no way back.
4. Per model. The same eval across models, because a policy that one model honours and another ignores is a finding about the model as much as the policy.
5. Per harness. The same eval through the products that say they log, control and enforce agent behaviour. If a harness enforces at twin 3, the footprint shows rows blocked that the bare run reached. If it only logs, the footprints match and the claim is measured.

What already exists

The list below is what the brief could verify from the published record. The Librarian's pass through the __Send project is in the next section.

What the __Send project already holds

The Librarian of the SG/Send project was asked six questions against the repository at v0.33.69. Paths are inside that repository; nothing was changed. The short version is that the chat, the file system, the bridge and the commercial model are further along than the memo remembered, and the twins are entirely on paper.

Three consequences for the plan. Twin 1 is the memory file system with an inbox shape on it, so it is days, not a week. The service-twin brief and this brief want the same word for different things; this brief uses twin for a simulation and leaves broker for the thing that holds a credential and executes on the agent's behalf, which is the rename the August brief already proposed. And the credits question was never a technical one: the mechanism, a bounded key sealed in a vault, has been specified three times. What stopped it is the page to sell from and the legal position, which is exactly what the two sections below are about.

Whose key: the four ways a model gets called

The sandbox is useless without a real model, and the site has no server, so every call is made from the browser. That leaves four ways to reach a model, and they are not alternatives: a shipped sandbox should support all four and say plainly what each one costs and who holds what.

Can we sell keys? What the terms actually say

This is a question for a lawyer, and the brief does not answer it. What it can do is put the clauses on the table so the lawyer's question is precise.

OpenRouter. Its Terms of Service prohibit using the service "for purposes of reselling API access to Models or otherwise developing a competing service" (section 7, item 4) and prohibit any attempt to "sell or otherwise transfer the access granted under these Terms" (section 7, item 14). The same terms, in section 5, contemplate "your customers (to the extent you incorporate the Service into your own products and services)" and require that those customers use the models only within the agreement and the model terms. So the line OpenRouter draws is between reselling access, which is forbidden, and a product that uses the service, which is expected. That distinction is the whole question for us.

Where the sandbox sits on that line. A sandbox eval is a product: our prompts, our tools, our twins, a defined task, a scored result. A vault shipped with credits whose chat panel will send any prompt the user types to any model looks much more like access. The design choice that keeps the sandbox on the product side is to spend sold credits only inside the sandbox's own workflows, and to make the open chat panel bring-your-own-key only. That is a product decision with a legal consequence, and it should be made deliberately.

The precedents. Vercel sells AI Gateway credits and Cloudflare sells unified-billing credits, each with the provider's key held by them and never shown to the user. Both are, in plain terms, reselling model access, under whatever agreements they hold with the providers. Buying credits from a gateway that is permitted to resell, and spending them inside a product, is the cleanest version of the model the memo describes. It also moves the key out of the vault entirely, which answers the "whoever holds the vault key can read it" problem.

The ask to each provider. Not "may we resell your keys", which has a known answer, but: "we ship an encrypted vault that runs a defined evaluation workflow against a model; the vault carries a bounded credential with a small spend limit that we paid for; the user cannot extract the credential without the vault key and cannot use it outside the workflow; is that a product under your terms, or is it resale?" Ask it of OpenRouter, Anthropic, OpenAI, Google, Mistral, AWS, Azure, Cloudflare and Vercel, publish each answer as it arrives, and keep the page honest about who has not replied. That page is also, as the memo notes, the first time most of them will have seen a behaviour policy.

The provider map: who can cap spending, and how hard the cap is

An agent needs cost control the way it needs every other barrier: enforced above its own reach. The map below is what the vendors' own pages say as of 2 October 2026. It belongs in the sandbox as a live table, because it is one of the things the sandbox tests.

The pattern is plain. The model vendors and the gateways cap; the clouds alert. An agent on Bedrock, Azure or Vertex with no gateway in front has no spend barrier above its reach, only an expectation. That is a row in the policy, and the sandbox should show it as one.

The deployment model

The thing being sold is a vault. Three variants, in the order they should ship:

1. The public sandbox, a read-only vault with every eval, every twin and every published footprint, bring-your-own-key for anyone who wants to run it live. Free, and the demo.
2. A sandbox with credits, the same vault with a bounded credential sealed inside it, sold at a small fixed price, credits spent only inside the evals. Whether the credential is ours or a gateway's depends on the answers above.
3. A customer's own sandbox, seeded with their twins and their policies, run in their vault, with their key or their gateway. This is the RiskMandate product, and it is where the policy's licence to operate gets its evidence.

Two honest notes travel with all three. The key sealed in a vault is protected from the app and from a read-only session, not from a holder of the write key, and there is no arrangement of files that changes that; the only thing that does is a credential that is bounded, so that what the holder can spend is the credit and nothing more. And the bridge protects the key; it is not yet a boundary that stops an app calling a provider with a credential of its own. Both are stated in the __Send project's own documents and should be stated wherever the sandbox is sold.

Build plan

1. Twin 1, the inbox store, as the Vault Chat memory file system with an inbox shape on it, a seed generator and the Email-FS message shape. Days.
2. Twin 2, the OAuth connector, as a tool set over twin 1 with the Gmail scopes enforced and the real error shapes. Start from the Connector Twin's replay code. A week.
3. One eval, both ways. The clear-the-backlog task, one model, the bridge, policy off then on, footprints side by side in the vault. This is the first thing to show anyone. Two weeks including the UX.
4. Twin 3, the MCP connector, with the prompts and the always-allow behaviour, and the harness comparison on top of it.
5. The provider map as a live page, the legality tracker, and the agent-written letters to each provider, sent from the comms vault and logged on the page.
6. Credits, once the legal answer is in: bounded keys sealed in sold vaults, or a gateway account behind them.

Questions for the founders

1. Sandbox, evals, twins? The brief uses those three words. Say now if RiskMandate wants others, because they will be in every file name.
2. Sold credits inside the evals only, or in the open chat too? The first keeps the sandbox a product under the terms as read; the second is the better demo and the harder legal position.
3. Which gateway to approach first about carrying the credits, if any: Cloudflare, Vercel, OpenRouter, or one of the companies already spoken to.
4. Who signs the letters to the providers. The memo wants the agent to write them. The agent can, from the comms vault, under the byline the site already uses; the founder decides whether a person co-signs.

House rules. Every claim about a provider on this page links to the provider's own page and carries the date it was read. Terms change; the table says when it was last checked. Nothing here says the sandbox exists; it says which of its parts do.