> ## Documentation Index
> Fetch the complete documentation index at: https://docs.proofable.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Run your first guarded action

> Load current agent permissions and make one allow or deny decision before a host tool runs.

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](./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:

```bash theme={"system"}
npx -y @proofable/sdk mount guarded-demo --apply <host>
```

`<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`.

## 3. Evaluate before the tool call

```javascript theme={"system"}
import fs from 'node:fs';
import { evaluateRuntimeAction } from '@proofable/sdk/runtime-mount';

const bundle = JSON.parse(fs.readFileSync('.proofable/mount.json', 'utf8'));
const decision = evaluateRuntimeAction(bundle, 'send_message', {
  irreversible: true,
});

if (!decision.allowed) {
  throw new Error(`${decision.code}: ${decision.message}`);
}

await sendMessage();
```

For the permission above, `send_message` returns:

```json theme={"system"}
{
  "decision": "denied",
  "allowed": false,
  "action": "send_message",
  "code": "ACTION_DENIED"
}
```

`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:

1. Require a valid runtime mount and an unexpired mounted permission.
2. Apply `deniedActions`.
3. 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.
4. Require approval for an irreversible action when configured.
5. 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`](https://github.com/proofable/mcp/tree/main/examples/guarded-agent-action).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.