Audit logs
what is logged, what is not, retention
An audit log you cannot enumerate is a feeling, not a control. This page lists what we log, what we deliberately do not, how long entries live, and who can read them.
What is logged
- Every trust-kernel decision: scope requested, scope granted or denied, and the task that justified it.
- Authentication events — token issuance, validation failures, revocations.
- Administrative actions, each attributed to the admin key that performed them.
- Run-level traces: which context a run read, which models were routed, what actions resulted.
- Security-relevant API events: rate-limit triggers, honeypot hits, malformed-request rejections.
What is deliberately not logged
Logs are a data store too, and an over-collected log is a second breach waiting inside the first. We do not log document contents into audit trails — entries reference what was accessed, not what it said. We do not log credentials, token values, or form contents on rejected requests. IP addresses appear in rate-limit and security logs and age out with them.
Retention
- Trust-kernel and administrative audit entries: 365 days.
- Run traces: 90 days by default, configurable per enterprise workspace.
- Security and rate-limit logs: 30 days.
- On account deletion, logs tied to personal identity are deleted with the 30-day deletion pass; aggregate security telemetry survives in de-identified form.
Integrity and access
Audit entries are append-only at the application layer — there is no edit path, including for operators. Access to raw logs is restricted to the operator role, and that access is itself logged. Enterprise customers can request the audit trail for their own workspace; it arrives as structured export, not screenshots.