Approvals

An approval is a named person’s decision, made in LightHouse, that an agent’s output may count. An agent never approves its own work, and neither does a machine key.

When an agent waits

An agent whose card has an external effect (it sends, publishes or writes into one of your systems) is gated by its autonomy level:

• Level 1, sign-off: its output waits for a person.
• Level 2, pre-approved: it goes ahead if a standing pre-approval covers the action and its limits allow one more; otherwise it waits, as at level 1.
• Level 0, draft: a draft that nothing downstream may use.

Waiting is not failure. The run carries on with what does not depend on the output, and the agent shows awaiting-sign-off. See Agents.

Who can approve, and how it is enforced

• A person with the handler or client_admin role, signed in with a second factor.
• Your tenant’s command settings must switch approval.decide on, and your deployment’s policy must allow it.
• Where your deployment’s policy says approvals are managed by LightHouse (the default for new deployments), the engine accepts a decision only as a command signed by LightHouse. A product’s own buttons, a script or a local call are refused (approvals-managed-by-insights) and logged.
• If LightHouse cannot be reached, nothing is approved: items wait, and agents act only within standing pre-approvals.
• Your own break-glass, for named people only, is off by default. A decision made through it is recorded as such, and LightHouse writes it to your audit log, flagged.

Pre-approvals

A pre-approval lets a level-2 agent act without waiting, for one kind of action, within limits (max_per_day, max_total), until it expires or is revoked. Only a person your catalogue names as an approver may grant one. Each use is counted, and the decision it makes names the grant and the approver.

Grant, change and revoke them in LightHouse; read them with GET /api/v1/preapprovals or the preapprovals tool.

The audit trail

Every decision records who made it, when, the reason, how long the output waited, whether the person edited it, and the digest of what they were shown. Issuing the decision and its final status are both in your tenant’s audit log (Setup and admin → Audit, GET /api/v1/audit).

In the API

POST /api/v1/approvals/decisions, as a signed-in person only. See the Handler commands reference, and Approvals in Build agents for declaring where an agent must ask.