Confirm a destructive action
Handle 412 confirmation_required: mint a confirmation token and replay the call with X-Trustvice-Confirmation.
Handle 412 confirmation_required: mint a confirmation token and replay the call with X-Trustvice-Confirmation.
Agents, evidence, governance, commerce and disclosure are all in Trustvice 360. Sign up free and open every suite from one dashboard.
Your caller needs an action whose confirmationPolicy is "always", which covers every destructive and billing_impacting action. Trustvice refuses to run those until the request carries a fresh confirmation token: a human, or an explicit autonomy grant, must have said yes, recently, for this action.
curlThe code reads secrets from environment variables. Keep them in your shell or your secret store, never in a file you commit. Action calls also send X-Workspace-Id.
Call the gated action as usual. Without a token it answers 412 with the code confirmation_required. The docs use privacy.dsr.submit as the example.
The mint call returns the token in jti, the action it is bound to in audience and the time it expires.
{ "ok": true,
"jti": "cnf_…",
"audience": "privacy.dsr.submit",
"autonomous": false,
"expiresAt": "2026-09-14T13:20:37.675Z" }
Trustvice 360: trust and govern your AI agents with signed, verifiable evidence.
curl -sS -X POST https://api.trustvice.com/api/v1/actions/privacy.dsr.submit \
-H "Authorization: Bearer $TRUSTVICE_TOKEN" \
-H "X-Workspace-Id: ws_…" \
-H "Content-Type: application/json" \
-d '{ … }'{ "ok": false,
"error": { "code": "confirmation_required",
"message": "This action requires an explicit confirmation." } }Ask POST /api/v1/confirmations/mint for a token for that action id. The token is bound to the calling actor and to the action's audience, lives for seconds and is consumed on first use.
curl -sS -X POST https://api.trustvice.com/api/v1/confirmations/mint \
-H "Authorization: Bearer $TRUSTVICE_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "actionId": "privacy.dsr.submit" }'Send the same call again with the token's jti in X-Trustvice-Confirmation. The action now runs and returns its real result.
curl -sS -X POST https://api.trustvice.com/api/v1/actions/privacy.dsr.submit \
-H "Authorization: Bearer $TRUSTVICE_TOKEN" \
-H "X-Workspace-Id: ws_…" \
-H "X-Trustvice-Confirmation: cnf_…" \
-H "Content-Type: application/json" \
-d '{ … }'An agent that must call gated actions without a per-call human click holds an autonomy grant: time-boxed, with a safety ceiling, recorded against the workspace. Granting one needs a human confirmation token for the agents.autonomy.grant audience. While a covering grant is active, mint returns autonomous: true tokens for in-scope actions.
POST /api/v1/autonomy/grant { "maxSafetyLevel": …, "ttlSeconds": … }
POST /api/v1/autonomy/revoke
GET /api/v1/autonomy/statusCopied from: /docs/confirmations
Every statement above comes from the Trustvice docs linked on this page. Where a docs page says more, it is the reference.
Mint an OAuth access token, find an action in the public catalogue and call it at POST /api/v1/actions/<id>.
One short email when we add recipes to the cookbook. No other mail, and you can unsubscribe from any message.
One POST endpoint per registered action, with the same behaviour over REST and MCP. The docs list every action with its input and permissions.