Approvals.

Some actions should never happen on an AI’s say-so alone. The Execution Layer gates them behind a server-side approval that a person, who can be someone other than the one who asked, has to grant.

Risk classes

Actions are grouped into risk classes, and the destructive ones are gated by default: deleting records, mass updates, validating an invoice, confirming an order, sending outbound mail. You choose which classes require approval and who approves them.

Prepare, approve, execute

When a risk-classed action arrives, the layer does not run it. It stages the exact change server-side and refuses the call with APPROVAL_REQUIRED, opening an approval request:

prepare   the exact change is staged, server-side
approve   a person signs off on that exact payload
execute   only the approved payload runs

The agent then retries the identical call with the returned approval_request_id, and it executes.

The token is bound to the payload

The approval token binds the user, the tool, the model, the record ids, an exact hash of the payload, and the policy version. If anything drifts after approval, the write is refused as APPROVAL_STALE. You cannot approve “update this order” and have the AI quietly change a different field or a different record.

Four-eyes, through Odoo

Approval happens in Odoo, through the activity inbox and notifications, never through a tool the AI can call. That is what enforces approver is not the asker: the person who reviews and clicks Approve or Deny is a real Odoo user acting in Odoo, and it can be a manager rather than the requester.

The full list is in the error codes reference. Every approval, and every denial, is recorded in the audit.

Next: evidence and audit.