The audit log is the product.

What gets recorded

Every action the Brain initiates is recorded as a single, immutable row in an append-only audit table. That covers, at minimum:

• Identity events - sign-ins (successful and failed), sign-outs, password and email changes, MFA enrollment.
• Profile and organization events - profile updates, org creation and updates, member added/removed, role changes.
• Bridge events - when an MCP bridge is connected, scopes change, or a bridge is revoked.
• Action events - every action the Brain dispatches: the tool, the target, the inputs, who approved it, and the outcome.

The schema is intentionally narrow: what happened, who did it, when, against what, and with what context. Free-form metadata sits in a JSON column for action-specific details.

What's encrypted

Anything that could re-identify a person across data sets - the IP address that initiated a session, the user-agent string, billing-grade contact details - is stored as ciphertext. We use authenticated encryption (XChaCha20-Poly1305) with a Vault- managed key, with the column path bound into the AAD so a ciphertext can't be silently copied between fields.

Reads happen through a security-invoker view that decrypts only rows your row-level security policy already lets you see. Writes happen through a SECURITY DEFINER RPC - direct inserts against the base table are blocked at RLS.

Who can see what

• You see every audit row where you were the actor.
• Org admins see every audit row scoped to their organization.
• No one can update or delete an audit row through the application. Append-only is enforced at the database, not just the API.

Querying the log

Every audit row is a Postgres row. Filter by event kind, actor, org, time range, or target. The dashboard exposes the most common queries; for ad-hoc analysis, point your favorite SQL tool at the read replica.

-- "What did Alex actually do yesterday?"
select occurred_at, event_kind, target_table, target_id, metadata
  from audit_events_decrypted
 where actor_user_id = :alex
   and occurred_at >= now() - interval '1 day'
 order by occurred_at desc;

Retention

The default retention horizon is 13 months - long enough to cover any reasonable annual audit cycle plus a quarter of overlap. Enterprise tier customers can configure longer windows or lifecycle rules that move older partitions to cold storage.

Identity events (sign-ins, password changes) are retained for the full window without exception. Action events older than the window are pruned by a scheduled job; the prune itself is recorded.

Shipping to your SIEM

For Business and Enterprise tiers we forward audit rows to your SIEM in near real time. Supported sinks include Splunk HEC, Elastic, Datadog, and any S3-compatible object store via Parquet rollups. Schema is documented and versioned - we won't break a downstream pipeline without telling you a release ahead.

Designing your own approval policies

The audit log isn't only for forensics. Approval rules read it too. Want "no payment-link send-outs to a contact we've audited within the last 24 hours"? That's a rule that joins live state against the log. We document the canonical patterns in the handbook.