This flow proves that the host can stop a tool call when the current agent permission does not allow it.
1. Create a bounded agent
After MCP setup, ask your assistant:
Create or import an agent named guarded-demo. Allow read_proofs, deny send_message, and require human approval for irreversible actions.
The assistant uses proofable_agent_create and returns the one required setup step when signing is still needed.
2. Load current permissions
Run this in the project where the host will enforce the decision:
<host> is cursor, claude, codex, hermes, openclaw, or opencode. VS Code uses cursor. The command writes the current proofable.runtime-mount.v1 bundle to .proofable/mount.json.
For the permission above, send_message returns:
read_proofs returns ACTION_ALLOWED. A delegated permission with an empty or missing allowedActions list grants no actions. An expired or missing permission fails closed. An irreversible action returns HUMAN_APPROVAL_REQUIRED when the permission requires approval.
Decision order
evaluateRuntimeAction applies the mounted permission in this order:
- Require a valid runtime mount and an unexpired mounted permission.
- Apply
deniedActions.
- Require an explicit, non-empty
allowedActions list for delegated authority, then check the action against it. Controller-owned mounts do not require a delegation allowlist.
- Require approval for an irreversible action when configured.
- Allow the host tool call.
The SDK evaluates one action against the mounted snapshot, as of @proofable/sdk@0.1.4. Load that snapshot from a trusted mount; caller-supplied JSON is not a verified proof. The host still owns the tool call and must stop when allowed is false. A mount file cannot discover a revocation that happens after it was written; refresh current authority through the connected Proofable host before a consequential action that needs current revocation status.
Runnable source: examples/guarded-agent-action. Last modified on October 5, 2026