Audit log

The audit log captures every administrative action against your tenant: who did what, when, from which IP, against which resource. Retention is two-tier: a queryable hot tier with full event payload (actor, action, fields_json) for 90 / 180 / 365 / 730 days — defaulting to 90 (standard plan) or 365 (enterprise plans), and configurable per tenant at Authentication policy → Audit log retention; and a 3-year cryptographic chain archive in T Cloud Public OBS WORM that retains hash-chain anchor objects after the hot-tier payload has been redacted. Compliance exports cover the queryable window.

For the cryptographic chain of custody (anchor-chain, OBS-backed merkle commitments), see Audit chain integrity.

What’s recorded

Notably absent: ordinary code reads (clone, view, file open). The audit log is an administrative-action log, not an access log. If you need a read-event trail (e.g. for sensitive-IP review), open a support ticket, we’ll talk through the SIEM-forwarding shape that gets you there.

Reading the log

Tenant admin → Reports → Audit log. Filter by actor (<username>), action (secret.created, role.changed, …), time range, or affected resource. The default view is the last 7 days.

Click any row to expand the JSON payload. Sensitive fields (secret values, OIDC tokens, PII attachments) are redacted at the write boundary, so an expanded row never shows a value you wouldn’t want a customer’s auditor to read.

CSV export

Click Export CSV on any filtered view to get a snapshot. The CSV contains the rows currently filtered, capped at 50,000 rows per export. For larger windows, queue a full Data export from Reports → Data export.

Via REST API

The audit log is available on the public API surface. Use this when streaming events into your own analytics pipeline, building a compliance dashboard, or driving audit queries from a script.

• Query the log GET /api/v1/orgs/:slug/audit (filter with ?actor_kind= and ?since=)
• Verify chain integrity GET /api/v1/orgs/:slug/audit/integrity
• Change retention window PATCH /api/v1/orgs/:slug/auth-policy body: { "audit_full_payload_retention_days": 365 }

Requires a Personal Access Token (PAT) with the audit:read scope (or policy:write to change the retention window):

curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  "https://frem.sh/api/v1/orgs/acme/audit?actor_kind=human&since=2026-01-01T00:00:00Z"

See the public REST API reference for the full OpenAPI specification.

SIEM forwarding

Every audit event is also emitted to a per-tenant HTTPS sink if you configure SIEM forwarding. The sink receives events in real time (within seconds of the action) in a compact JSON shape; the format is stable and versioned.

Retention

Audit records are kept in two tiers:

1. Queryable payload tier — the actor name and fields_json payload of every event are queryable in the admin UI / CSV export / SIEM stream for the retention window below.
2. Tamper-evident chain tier — each event’s cryptographic hash + chain link stays for 3 years (WORM-anchored to OBS object lock). This is what makes the chain provably untampered for audit-readiness; it lives intact even after the payload tier redaction stamps a row.

Queryable payload retention

The cap of 730 days (≈2 years) keeps the live audit_events table bounded. Anything beyond that is the WORM tier’s job; if you need queryable history past 730 days, queue a Data export quarterly and archive it in your SIEM.

The cutoff applies at the actor + fields_json columns: rows older than the window keep their hash, timestamp, and action name (so SOC 2 / DORA reporting still works) but the actor is pseudonymised to redacted and the payload is replaced with {}. The cryptographic chain is not broken by this; redaction is an in-place pseudonymisation, not a delete.

Changing the queryable window

Tenant admin → Security → Authentication policy → Audit log retention card. Pick one of 90 / 180 / 365 / 730 days. Behaviour notes:

• Extending the window (e.g. 90 → 365): newly-emitted rows stay queryable for longer. Rows that were already redacted under the previous window stay redacted — fremforge does not un-redact.
• Shortening the window (e.g. 365 → 90): the next daily redaction sweep redacts every row older than the new window. Redaction cannot be undone once applied; the WORM chain is unaffected.

Audit-log action recorded against this setting: tenant.auth_policy.audit_retention.updated (with previous and next day counts).

Compliance commitments

DPA Annex A.7 commits to the 90-day baseline + 3-year WORM. Enterprise SLA commits to 365-day queryable + 3-year WORM. Going below the plan default is allowed in the UI but would breach the DPA — fremforge does not enforce the floor at the column, the contract does. A failure of the daily redaction sweep itself (separate from a customer changing retention) is monitored and alerted continuously.