Audit log for every AI agent write

Gate records an immutable audit trail for every agent action — who proposed the write, which policy evaluated it, who approved it, and whether it executed. Every event timestamped. Every actor named. Queryable via API.

The AI agent audit gap

SOC 2 and enterprise AI governance frameworks require evidence of control over AI-driven actions. Application logs record that a function was called. They do not record what the agent intended, what policy applied, who approved the action, or whether the action succeeded.

Gate records all 5 dimensions for every agent write:

1. Intent — what the agent proposed, payload hash, destination, record count
2. Policy evaluation — which policy ran, result, reason code
3. Risk assessment — composite score 0–1, level (low/medium/high/critical)
4. Approval — auto-approved by policy, or named human reviewer + timestamp
5. Execution outcome — succeeded or failed, reported by worker

The audit trail — live example

Every intent generates a queryable event log. The canonical audit trail for an approved write contains 5 events in sequence:

Retrieve the full audit trail with a single API call:

GET /v1/intents/:id/audit
Authorization: Bearer gate_sk_...

{
  "intentId": "int_6e5342…",
  "events": [
    { "event_type": "proposed",              "actor": "crm-sync-agent", "created_at": "…" },
    { "event_type": "policy_checked",        "actor": "system",         "created_at": "…" },
    { "event_type": "approved",              "actor": "sarah@co.com",   "created_at": "…" },
    { "event_type": "execution_requested",   "actor": "crm-sync-agent", "created_at": "…" },
    { "event_type": "execution_succeeded",   "actor": "runner",         "created_at": "…" }
  ]
}

Policy decisions — stored separately

Gate stores the policy decision record independently from the audit trail. The GET /v1/intents/:id/decision endpoint returns the exact policy snapshot evaluated — reason code, risk score, risk level, and timestamp — queryable indefinitely after the fact.

The 6 reason codes Gate records:

1. approved_by_policy — auto-approved, under all thresholds
2. record_threshold_exceeded — batch size over auto-approve limit
3. blocked_term_detected — payload matched a blocked term
4. destination_not_allowed — destination not in policy allowlist
5. sensitive_data_detected — sensitivity tag triggered manual review
6. manual_review_required — policy requires human approval always

Multi-agent accountability — on_behalf_of

Orchestrator architectures create accountability gaps. A leaf agent submits a write. The orchestrator that instructed it is unrecorded. Gate's on_behalf_of field closes that gap.

The leaf agent records the orchestrator agent ID in every intent it submits. The audit trail shows the full instruction chain — orchestrator instructed leaf agent; leaf agent submitted intent; Gate evaluated policy; human approved.

What Gate does not (yet) guarantee

Gate records an accurate audit trail. The audit log is append-only in SQLite (WAL mode). 2 properties are on the roadmap, not yet shipped:

1. Cryptographic signing — audit events are not yet individually signed; a database admin can edit them
2. External log drain — events are in SQLite only; no S3/Splunk/SIEM export yet

For compliance use cases that require tamper-evident logs, pair Gate with an external append-only log service. Gate's audit API provides the structured event stream.

Compliance coverage by control type