Approvals & audit

The flow

When a policy evaluation resolves to REQUIRE_APPROVAL, Aegis creates an approval request in the same transaction as the evaluation — there is no window where a decision exists without a corresponding request. An authorized team member (Owner, Admin, or Security role) reviews it, with full context: the action, the amount or resource involved, which policy triggered the requirement, and the agent’s recent history.

Approving or rejecting records an immutable decision, with an optional comment. Resolution is race-safe — if two people act on the same request at once, exactly one resolution succeeds and the other is told the request was already resolved, rather than silently double-processing it.

Polling for a decision

An external agent process (via the SDK’s waitForApproval() or by polling GET /api/v1/approvals/:id directly) can wait for a pending request to resolve, with capped backoff and a timeout, so it never blocks forever waiting on a human.

The audit trail

Every policy and permission change, every agent mutation, and every step of the approval lifecycle (request created, approved, rejected, expired) is written to an append-only audit log in the same transaction as the action it describes. There is no update or delete path for audit data — if something needs correcting, that’s a new entry, not a rewritten one.

Trace correlation

Every request carries a traceId that threads through the activity event, the policy evaluation, the approval request, and the resulting audit events — so you can follow one agent action end-to-end from a single id.