Audit Logs
The audit log records which actor changed which resource, and how — in a project across all its modules and the platform, and in an agency for the agency itself. It answers the question “who did that?” months later.
Entries are only ever added — the application never edits or deletes them.
| Where | Who can see it | |
|---|---|---|
| Project | Governance › Audit Logs | Members with the Auditor role (Admins included) |
| Agency | Governance › Audit Logs | Members with the Auditor role (Owners included) |
What is recorded
Section titled “What is recorded”Every entry captures:
| Field | Contents |
|---|---|
| Time | When it happened |
| Actor | Who did it — a user, an API key, an automation of TrustComponent (a scheduled job, for example), an anonymous caller (a failed sign-in, for example) or the system |
| Subject | What was changed — a member, an API key, an SSO configuration, a monitor, a status page, a validation schedule, an invoice … |
| Action | What happened — created, updated, deleted, invited, accepted, revoked, rotated, locked, sent, exported … |
| Changes | Field by field, before → after. Secret values are never recorded and show as redacted. |
| Details | Facts about the action that are not a change — the sign-in method of a sign-in, the format and time range of an export |
Expand an entry to see its changes and details.
Viewing and exporting
Section titled “Viewing and exporting”- Choose the time range with the date range picker; it starts with the last 24 hours.
- How far back you can look depends on your plan and add-ons. Entries are stored for two years; older ones are deleted.
- Export the selected range as JSON, CSV or Excel. Every export is itself recorded in the audit log. Whether export is available depends on your plan and add-ons.
Your own systems can read the same entries through the audit log API, or receive every new entry through streaming.
Project activity
Section titled “Project activity”Agency › Governance › Project activity shows the audit logs of your client projects in one place, for the most recently connected projects. Each project keeps its events for its own retention, and you only see projects in which you hold the Auditor role — for example as a client project role. Projects without it are skipped and counted.
The agency’s own audit log does not contain the events of its client projects.
Streaming
Section titled “Streaming”Streaming sends every new audit log event as one JSON document — exactly the event format of the audit log API — by HTTPS POST to a destination of your choice. Deliveries that fail are retried several times. Destinations are managed by members with the Auditor role; whether streaming is available depends on your plan and add-ons.
- Open Governance › Audit Logs and choose New Destination in the Streaming section.
- Pick the type and fill in the fields below.
- Open the menu of the destination and choose Send test event. You see right away whether your platform accepted it.
Create an HTTP Event Collector token in Splunk and enter the address of the collector (for example https://splunk.example.com:8088) and the token. TrustComponent sends to /services/collector/raw?sourcetype=_json with the header Authorization: Splunk <token>. If your collector requires indexer acknowledgement, edit the destination afterwards and add the header X-Splunk-Request-Channel.
Choose your Datadog site and enter an API key. TrustComponent sends to the logs intake of your site with ddsource=trustcomponent and service=trustcomponent-audit-log, so you can filter for it right away.
Enter the Elasticsearch endpoint of your deployment, the index and a base64-encoded API key with write access to it. TrustComponent sends to /<index>/_doc. A regular index works as is; a data stream needs an ingest pipeline that sets @timestamp from occurredAt.
Any HTTPS endpoint that accepts a JSON POST. Add the headers your endpoint needs, for example an Authorization header.
A delivery that is retried keeps its body, so use the id of the event to skip one you already stored. Every request carries the headers TC-Webhook-Id, TC-Webhook-Event (platform.audit-event.created, or platform.export-destination.test for a test event) and TC-Webhook-Timestamp. TC-Webhook-Signature has the form t=<timestamp>,v1=<signature>, where the signature is the hex-encoded HMAC-SHA256 of <timestamp>.<body> with the signing secret shown when you edit the destination. Check it if your endpoint is reachable from the internet.
If your plan no longer includes streaming, existing destinations are suspended: they receive nothing, and you can only pause or delete them. After an upgrade, active destinations continue on their own.
Related pages
Section titled “Related pages”
