Approval Auditing

Every human-approval decision is recorded in a tamper-evident, append-only ledger — who decided what, when, and through which channel.

Human approval gates a privileged tool call on a person's sign-off. Because that sign-off authorizes something the model otherwise couldn't do — a refund, a deletion, an outbound message — Fruxon records every approval in an append-only audit ledger, so you can always answer who approved this, when, and how.

What gets recorded

Each approval gate writes one ledger entry per lifecycle transition:

Event	When
Requested	The gate fired and the run paused. Captures the gated tool and a snapshot of the exact arguments put up for approval.
Responded	A person approved or rejected. Captures the decision and any comment or rejection reason.
Cancelled	The request was abandoned — an operator cancelled it, or the run was torn down — before a decision.
Expired	No one responded before the request's time-to-live elapsed.

Every entry also records:

Actor — who (or what) caused the event.
Channel — the surface the action came through, which also tells you what kind of identity the actor is:
- Web — an admin responded in the dashboard or via the API. The actor is a Fruxon user.
- Connector — someone replied through the messaging channel the request was delivered to (Slack, Telegram, …). The actor is the verified participant — see Who can approve.
- Discussion — the decision came out of a back-and-forth discussion with a participant rather than a one-shot reply.
- System — an automatic transition: the gate creating the request, the time-to-live expiring it, or a torn-down run withdrawing it.
Decision — Approve or Reject (on Responded entries).
The timestamp, the agent and session, and the originating request id for correlation.

Tamper-evident by design

The ledger is append-only. Entries are never updated or deleted — not by the agent, and not by the application itself: the database role Fruxon runs as has UPDATE, DELETE, and TRUNCATE revoked on the audit table. A bug or a compromised application credential can't rewrite history. The decision recorded against an approval is the decision that was made.

The pending-approval record is updated in place as a request resolves, so it only ever shows the final state. The ledger — not that record — is the authoritative history of what happened over time, including the requested arguments as they stood at decision time.

Reading the trail

There are two ways to review approval history:

In the trace. Every gated step in Execution History shows the decision, who responded, how long the run waited, and the route the request was sent to — for that one run.
Per request, via the API. For the full transition-by-transition timeline of a single approval, read its audit events:
```
GET /v1/{tenant}/agents/{agent}/pendingApprovals/{approvalId}/auditEvents
```
Events come back newest-first with cursor pagination, scoped to the agent in the route. Requires the executions:read scope.

Who can approve

Approving a gated call authorizes a privileged action, so Fruxon restricts who can do it on each channel — and the ledger captures the verified identity, not a self-declared one.

Dashboard / API — responding requires the Admin role on the agent. Viewers can see pending approvals and history but can't act on them. The responder's identity comes from their authenticated session, never from the request body, so the trail reflects the real user.
Messaging channels — when an approval is delivered to a connector, only the participant bound to the agent's approver slot can authorize it. A reply from anyone else — or one that merely references the request through a forwarded or leaked message id or correlation token — is ignored, not honored. The ledger records the verified participant as the actor.

Recording is fail-closed

Recording a human decision is a precondition, not a side effect. If Fruxon can't durably write the ledger entry for an approve, reject, or operator cancel, the decision is not finalized and the run does not resume — the request stays pending so it can be retried. An approval never proceeds on a decision that couldn't be recorded.

Automatic transitions — request creation and expiry — are recorded best-effort and never block a run.

Human approval — putting a tool behind an approval gate
Execution History — approval decisions inside a single run's trace
Security — keeping destructive actions behind a human
Agent network — participants, slots, and how approval requests reach a person