Govern your first agent action in two minutes
No account, no KYB, nothing to provision. Start with a live call to the real gate from this page, then scaffold a governed agent, then run the full three-party demo.
Try it here, against the live gate
This is not a simulation. Provisioning calls the public no-KYB endpoint, your browser signs the canonical message, and the verdict comes back from the same gate every production agent calls.
Call the real gate
No account, no install. This provisions a real sandbox agent and signs in your browser — the verdicts below come from the same gate production agents call.
Provision an agent to enable the scenarios.
Scaffold a governed agent
One command provisions an identity, a mandate, the Standards it must comply with and a spend-cap SOP, then writes a runnable project. Still no account and no KYB — which is also why this shared identity stays single-process; see Step 3 for what changes once you provision your own.
# no login, no KYB — a governed agent in one command
npx create-metamynd-agent --sandbox
cd metamynd-sandbox
npm install
npm start # four attempts: ALLOW and ESCALATE come from the live gate;
# over-cap and never-granted are refused locally from the
# agent's signed rules, then reported for auditProvision an agent you own
Drop --sandbox and the same command provisions an agent under your account: your own limits and merchants, an owner (you) who can approve, contain or revoke it from the dashboard, and a separate gateway process that holds the tool and independently re-verifies every request.
- Identity check. On this beta your principal is approved automatically, with no identity check, and is limited to testnet. The Principals page says so. Mainnet needs a verified principal.
- An escalation. It waits under Dashboard → AgentSafe → Escalations. Approve it there, then
npm run resume -- <escalationId>runs it exactly once. In your own agent that is one call:await gatedTool.resume(escalationId, sameArgs). - Changing the rules. Edit the agent's SOP in the dashboard. Running gateways pick the change up within seconds, with no redeploy.
# 1. Create an account at https://metamynd.ai/auth/signup and confirm your email.
# 2. Provision your own agent. One command: identity, mandate, SOP, Standards,
# and a separate gateway process that is the real enforcement boundary.
# (Logging in here signs your browser out of the dashboard — sign in again after.)
npx create-metamynd-agent@latest \
--email [email protected] \
--name "Travel Bot" --scope flight-purchase \
--per-txn-max 150 --max-amount 2000 --merchants skyward-air,blue-sky
# 3. Start the gateway first, in its own terminal…
cd travel-bot/gateway
npm install
npm start
# 4. …then the agent, in a second terminal (from the same starting directory).
cd travel-bot
npm install
npm start # ALLOW runs in ./gateway; over-cap and ungranted refused;
# high risk waits in Dashboard → AgentSafe → Escalations
# 5. Approve it there, then run it - exactly once:
npm run resume -- <escalationId>Govern the agent you already have — free, on your own machine
Step 2 called our hosted no-KYB endpoint. This calls nothing of ours: guardToolLocal() decides allow / block / escalate against a rules file you author, using the same deterministic evaluator (policy-core) the hosted gate runs — zero network calls for the decision itself. Bring it to your existing agent's own tool calls; it doesn't need to be a fresh project.
# no login, no KYB, no network call for a decision — a free local governance
# harness for the agent you already have. Not a demo project: your own rules, your
# own identity, decided entirely on this machine.
npx create-metamynd-agent@latest --harness
cd metamynd-agent
npm install
npm start # ALLOW / BLOCK / ESCALATE — decided locally, a dashboard for the restA small local dashboard (127.0.0.1:4400 by default) holds any escalated action for you to approve, and lets you add, edit or delete rules from a form instead of hand-editing JSON.
Without MetaMynd, you can be bypassed. guardToolLocal() is a cooperative library your own process embeds, not a separate enforcement boundary — call the raw handler directly instead of the guarded one and nothing stops you, because there is no counterparty in the loop to disagree with you. That property comes from the three-party demo above, where the tool service independently re-checks the agent's authority for itself — and it's what npx create-metamynd-agent scaffolds by default now, as a second local process, without needing the full platform deployed. Use the harness to govern your own agent's own honest behavior; move to the hosted platform when you need a boundary a compromised agent can't talk its way around.
Hand this to your own coding agent
A ready-to-paste prompt for whatever you already use to write code — it wires the harness into your agent's actual tool calls, not a toy example, and it ends by asking your agent to try to defeat its own wrapping and report the honest result.
You already have a working AI agent. Add real governance to it — a wrapper around the actions that matter, not a rewrite.
1. Run `npx create-metamynd-agent@latest --harness` in a scratch directory to see the
reference shape: a generated identity (agent.metamynd.json), a starter rules file
(metamynd-rules.json — a spend cap + a high-risk-review rule by default), and a local
dashboard. Read metamynd-rules.json and harness-server.mjs before wiring anything.
2. In THIS project, add `@metamynd/agentsafe-guard` as a dependency. Bring over
agent.metamynd.json and metamynd-rules.json (or point at your own paths).
3. List every action this agent takes that has a real effect — spends money, calls a paid
API, sends a message on someone's behalf, writes or deletes data, executes code. Read-only
actions (search, lookups) don't need this.
4. For each one, wrap it with guard.guardToolLocal(action, handler, mapArgs, () =>
JSON.parse(readFileSync("./metamynd-rules.json"))) instead of calling it directly. Handle
all three outcomes: allow (proceed), block (refuse, surface the reasonCode plainly),
escalate (hold it — approve at the dashboard, or wire your own approval step).
5. Edit metamynd-rules.json (or use the dashboard) to set the REAL limits this agent should
have — not the starter defaults. A cap ten times the actual budget isn't a control.
6. Prove it, don't just wire it: run a case inside the limit (expect allow) and one outside it
(expect block). Then try to call the raw handler directly, bypassing the guard, and report
what actually stops it — honestly, even if the honest answer is "nothing does, this is
cooperative."
This is free, runs entirely on this machine, and needs no account — but without MetaMynd, you
can be bypassed: it's a library this process embeds, not a separate enforcement boundary. If
you need a boundary a compromised agent can't talk its way around — a counterparty that
independently re-checks authority, anchored evidence, a queue someone else can approve from —
drop --harness and provision normally. The same guardTool() call keeps working, and the CLI now
scaffolds that counterparty by default: a second gateway process holding the tool, so there's
nothing local left to call directly.Wrap a tool with the guard
The guard signs every request and runs the tool only when the gate allows it. A request the agent's signed rules already refuse is stopped locally, with no network call, and reported. It is zero-dependency and fails closed: if the gate is unreachable (GATE_UNREACHABLE), the action does not happen.
import { createGuardFromConfig } from "@metamynd/agentsafe-guard";
const guard = await createGuardFromConfig("./agent.metamynd.json");
// The tool runs ONLY if the gate allows it. A block or an escalate throws — including
// one the signed rules decide locally, and GATE_UNREACHABLE when there is no gate.
const bookFlight = guard.guardTool("flight-purchase", rawBookFlight, (a) => ({
amount: a.amount,
currency: "USD",
merchant: a.merchant,
context: { riskLevel: a.riskLevel },
}));Without MetaMynd, you can be bypassed. This snippet on its own is the same cooperative check the harness above uses — rawBookFlight still runs in this process, so anything able to call it directly instead of bookFlight gets the same result the gate would have given it. npx create-metamynd-agent (drop --sandbox) scaffolds the fix by default now: a second gateway process that holds the tool and independently re-verifies every request, the same trustless check Step 4 demonstrates at full scale below.
Make it a build step
Assert in CI that your agent cannot exceed its mandate, and fail the build if it can. A control a pull request has to pass is a different thing from a dashboard somebody remembers to check — and a control your mandate never actually set is reported rather than quietly passing.
# Assert this agent cannot exceed its mandate. Exit 1 if it can.
npx @metamynd/agentsafe-guard verify
# ok refuses an action the mandate never granted → block/NO_PERMISSION_FOR_ACTION
# ok refuses 501 against a cap of 500 → block/SOP_SPEND_CAP
# n/a no merchant allow-list in this mandate
# EVERY merchant is permitted
# --require turns "not configured" into a build failure:
npx @metamynd/agentsafe-guard verify --require merchants,perTxnThree parties, enforcing independently
A single governed agent is half the story. The demo that ships with the platform runs three independent parties: an agent with an embedded guard, a tool service that re-verifies the agent's authority for itself, and a human owner who approves what gets escalated.
The tool service is the part that matters. It does not trust that the agent's own guard ran — it re-evaluates the signed request against the agent's published policy for itself. An agent that ignores its own refusal still cannot get the service to act.
| The agent tries to… | Control | What happens |
|---|---|---|
| Books within its mandate | passes every check | allow → pay → booking confirmed |
| Books over its spend cap | SOP spend cap | block SOP_SPEND_CAP — the service is never called |
| High-risk booking | Standard escalate | escalate → owner approves → resumes |
| Restricted jurisdiction | SOP jurisdiction | block SOP_JURISDICTION |
| Agent ignores its own block | counterparty re-check | the MCP server blocks it anyway |
| Agent overpays | payment binding | AMOUNT_MISMATCH at settlement |
| Proves compliance privately | zero-knowledge | ZK_POLICY_OK — the amount is never revealed |
| Authorizes A, executes B | capability binding | COMMITMENT_MISMATCH — the swap is refused |
How to run it
- 1Open all three in separate tabs and put them side by side — the point is watching three independent parties disagree.
- 2In the agent, run “Books within its mandate”. Watch the tool service log its own decision: it re-verified, it did not take the agent's word.
- 3Run “Books over its spend cap”. The agent refuses before calling anyone — the tool service never even sees it.
- 4Run “Agent ignores its own block”. Now the tool service blocks it. That is the whole argument: a compromised agent still cannot make an honest service act.
- 5Run “High-risk booking”. It escalates and stops. Go to the owner's tab, approve it, then press Resume in the agent.
This deployment stops at the authorization hold rather than settling a payment, so the shared demo mandate is never spent. Every governance step is real; only the final settlement is skipped, and the agent says so where it happens.
Every claim on this page is checkable
- The gate is public — anyone can check any agent's authority
- Verdicts are deterministic and carry a published reason code
- A replayed request is refused, once the nonce is spent
- A forged signature is refused before anything is evaluated
- The rules are the organisation's, editable without a redeploy
- Every decision is anchored so it can be verified without us
Ready to move past the sandbox? The gate you just called is the same one production agents call — here’s exactly what changes and what doesn’t.
What changes in productionReady to govern your own agents
Bring your own identity and mandates, or ask for a walkthrough of the full three-party demo.