Action policy

It puts each agent action in one of three levels: automatic, confirm or forbidden. It defines how a person approves an action: tied to the exact action, with an expiry, and one time only. It also defines what goes into the log. The example is the same support case as examples/policies/soporte.json.
Copy the block with the button in its corner, or open the file on GitHub.
# Action policy: [agent name]

<!--
How to use this template:
- List every action the agent can propose and give it a level.
- Code enforces the policy, outside the model. A rule in the prompt is not a control.
- The example is a support agent. It is the same case as examples/policies/soporte.json,
  so tool and operation names stay as they are in that file.
-->

- Agent: [name]
- Policy owner: [name]
- Version and date: [v1, YYYY-MM-DD]

## The three levels

| Level | What it means | When an action goes here |
|---|---|---|
| Automatic | The agent runs it without a person. | Reads. Cheap, reversible writes within scope. |
| Confirm | A person approves this exact action before it runs. | Money, outbound messages, changes that are hard to undo. |
| Forbidden | The agent never runs it, even if someone approves. | Irreversible, bulk or out-of-scope actions. |

Action not listed in the table: confirm.

## Actions

<!--
One row per tool and operation. A rule with tool and operation wins over a rule with the tool only.
soporte.json stores the tool, the operation and the level. The policy can't express amounts.
The refund cap applies twice. First, the refunds tool rejects an amount above the cap.
Second, the amount is part of the approved action (it goes into the hash).
-->

| Tool | Operation | Level | Condition | Why |
|---|---|---|---|---|
| pedidos (orders) | leer (read) | automatic | Only orders of the customer who is writing. | Reading an order changes nothing and sends nothing outside. |
| clientes (customers) | leer (read) | automatic | Only the customer who is writing. | It is a read. It is still logged, because it is personal data. |
| clientes (customers) | any other | confirm | None. | A person checks any other change to a customer before it runs. |
| clientes (customers) | borrar (delete) | forbidden | None. | Deleting a customer cannot be undone. A person does it, outside the agent. |
| reembolsos (refunds) | crear (create) | confirm | Up to [cap] per order: the tool rejects a higher amount. Above the cap, a person handles it outside the agent. | It moves money. A person approves the exact amount before it goes out. |
| correo (email) | enviar (send) | confirm | Only to the order's owner. | It communicates outward. A person sees the exact text before it is sent. |
| [...] | [...] | [...] | [...] | [...] |
| any other | any other | confirm | None. | When in doubt, a person decides. |

## How approval works

- Approval is bound to the exact action: tool, operation, target and parameters. Code computes a hash (a unique fingerprint) of that data.
- If a parameter changes, the approval no longer applies. The agent asks for a new one.
- Approval expires after [__] minutes.
- Approval works once. Code never runs the same hash twice.
- Include a request or run id in the hash. Otherwise two legitimate, identical actions share a hash and code blocks the second one.
- If something fails or data is missing, the action doesn't run.
- The approver sees the action, the parameters, why the agent proposes it and the data it read to propose it.
- Who can approve: [roles]. Who can't: [roles, for example the person who requested the task].

## What gets logged

| Field | Example |
|---|---|
| Date and time (UTC) | [2026-11-01T14:02:11Z] |
| Run and agent identity | [run 8812, agente-soporte] |
| Full action and its hash | [reembolsos.crear, order 4471, amount, hash] |
| Level and rule applied | [confirm, rule reembolsos.crear] |
| Proposal: what the agent read and why it proposed the action | [reference to the trace, the step-by-step record of the run] |
| Authorization: who approved or denied, and when | [name, time] |
| Result | [executed / blocked / expired / error] |

- The agent can't delete or edit the log.
- Retention: [period], per [internal rule or law].

## Policy review

- Every [period], the owner reviews which actions moved from confirm to automatic, and why.
- We measure how many approvals each person makes per hour and how many they deny. If nobody denies anything, we check whether people read what they approve.

## Why this is here

- If a session combines untrusted content, sensitive data and external actions, the agent needs human oversight: *Agents Rule of Two* (Meta, 2025). A rule written in the prompt is not a control, so the code enforces the approval: *An AI agent deleted our production database* (Hacker News, 2026).
- Three levels (automatic, confirm, forbidden), and watch the actions that drift from confirm to automatic: *AI agents are easy to build. Accountability is harder.* (r/AI_Agents, 2026).
- People who approve many actions stop reading them. In a game, players approved 1 in 3 threats: *Humans missed 1 in 3 threats approving AI agent commands across 40k game runs* (Hacker News, 2026).
- Giving the agent more permissions or autonomy than the task needs is a risk of its own. Ask for least privilege per tool and human approval for destructive actions: *OWASP Top 10 for Agentic Applications for 2026* (OWASP, 2025).