Audit & evidence
Security
The audit log is the evidence layer beneath every Greenlight action. Platform actions, agent actions, IT actions, integration calls — all of them write a record with actor, target, diff, and reason. It is append-only at the data layer and exposed read-only through the dashboard and the audit API.
The categories of recorded events are listed in Observability & audit. This page covers how a security reviewer or compliance auditor uses the log as evidence.
What’s evidence-grade
Every audit event records:
- A monotonic, time-ordered identifier.
- The wall-clock timestamp at the control plane.
- The actor’s user id, the actor kind (
humanoragent), and the session that produced the action. - The target object — app, integration, policy, Knowledge entry, role assignment, etc.
- A structured diff for events that change state.
- The reason text for events that require justification (overrides, kill-switch invocations).
The structured form is consistent across event types. Auditors don’t have to interpret different shapes for “policy override” vs “Knowledge accepted” vs “integration revoked” — the wrapping is the same.
Retention
Retention horizon is configured per organization, with a platform-enforced minimum that satisfies common compliance requirements. Old events are not archived to cold storage and re-fetched on demand; they remain in the live store for the entire retention window. Search and exports work uniformly across the full window.
When the retention window expires, events are purged. Retention extensions are configurable upward without operational ceremony.
Exports
The audit log can be exported as CSV or JSON for any time range. Common patterns:
- A quarterly export for SOC 2 or ISO evidence files.
- A targeted export filtered by user, app, or integration for an internal investigation.
- A continuous export to a customer-side SIEM via the webhook integration.
The webhook integration pushes events to any HTTPS endpoint with HMAC signing. Splunk, Datadog, Sumo Logic, and homegrown audit pipelines all consume it without bespoke adapters.
Querying
The dashboard’s audit view supports filters across the structured event fields: actor, actor kind, target kind, target id, event type, time range. Saved filter sets give IT a consistent view of “the things this week we want to keep watching.” Query results paginate; large queries that need offline analysis use the export path instead.
There is no separate query language to learn. The filters are typed fields; everything composable through the UI is composable through the audit API the same way.
Tamper resistance
Today the log is append-only at the storage layer, with access restricted to org admins through the dashboard and the audit API. The next hardening step is HMAC chaining over a customer-held key, with the chain head exported to the customer’s own append-only object store. This puts the log into a tamper-evident posture: a missing record or a quietly altered field shows up as a chain mismatch the customer detects.
What’s not in the log
Request and response bodies for runtime traffic are not in the audit log. Audit records reference an integration call and capture the call’s metadata (URL, method, response code, latency, bound user), but they do not store payloads. Apps and integrations that need payload-level evidence — for example, an SAR fulfillment trail — should write that into their own dedicated store; Greenlight’s audit log is not designed to be a payload archive.