Public beta · the BotShield app is live on the web.
Console

Require a person’s yes before an agent acts on you.

One rule that holds for every runtime, listed or not: on the acts that matter, take the order only with a signed Proof of Resolution, and verify it in your own code. The runtime’s approval stays inside the runtime. This one travels.

The rule · three steps

Require it. Refuse without it. Verify before you execute.

Your code, not a policy. The agent proposes; the person answers on their own phone; you check the signature and the request id before anything runs.

1 · Decide the acts.

A payout, a refund, a post that counts, an account change, an order above your threshold. Everything else runs as it always has.

2 · Require the proof.

Your tool or endpoint takes a resolution_jwt on those acts. Without one, return a structured awaiting_human_approval with the request_id, so the model re-calls with the same id and no second card is minted.

3 · Verify before you execute.

ES256 against BotShield’s public JWKS. Check the issuer, the audience (the agent), the jti (your request id), the expiry and the verdict. Idempotency on the request id closes the rest.

import { createRemoteJWKSet, jwtVerify } from 'jose';
const JWKS = createRemoteJWKSet(
  new URL('https://api.botshield.ai/.well-known/jwks.json'));

export async function requireYes(resolutionJwt, agentId, requestId) {
  const { payload } = await jwtVerify(resolutionJwt, JWKS, {
    issuer: 'https://api.botshield.ai',
    audience: agentId, algorithms: ['ES256'],
  });
  if (payload.jti !== requestId) throw new Error('proof is for another request');
  if (payload.verdict !== 'approve') throw new Error('the person did not say yes');
  return payload; // sub is a pairwise handle — never a name
}

Twelve lines, any language. Your executor runs this before the act, or the act does not run.

Common questions

Require a person’s yes · FAQ

Does this work with any agent runtime, listed or not?
Yes. The rule is on your side. Any runtime that reaches your act without the proof is refused the same way, listed or not, reviewed or not.
What if the agent never asks the person?
Then it never gets a proof, and your code refuses. Nothing in any runtime forces an agent to ask; your executor forces it by declining to run. The model asks, your code enforces.
What does the proof tell me about the person?
That a person answered this request, and what they said. The subject is a pairwise handle for that agent — never a name, an email, or an id that follows them anywhere else.
Do I need Trusted Accounts for this?
No. The proof stands on its own. With a Trusted Account behind the order you also know a person is behind the account itself, on the same ID that answered.
This is BotShield MCP Tools

Place the rule behind one act.

Sandbox keys the moment you sign in. Ninety days on the free floor. Your login stays exactly as it is.