Audit logs
Find who changed what in ZopDay: filter the audit trail of every mutating call, isolate what an AI assistant did, export to CSV, and forward to your SIEM.
ZopDay writes every mutating API call (POST, PUT, PATCH, DELETE) to an audit trail, with the actor, the resource, the redacted request and response, and the outcome. The same data feeds the in-app Audit Logs page and your compliance evidence.
Activity → Audit Logs: every mutating call with who made it, what it touched, and whether it succeeded. Export CSV carries whatever filters are active.
Before you start
- The
audit-log:viewpolicy. Custom roles need an explicit grant; many organisations restrict it to security and compliance teams.
How it works
What gets captured
Each audit entry records:
- Actor: the signed-in user or the PAT that initiated the request.
- Method and path: the HTTP verb and the URL, with IDs preserved.
- Resource type and resource ID: the logical resource being acted on.
- Request body: the full body, with secret-shaped fields redacted (passwords, tokens, secrets, API keys, etc.).
- Response body: the full response, with the same redaction applied. MCP read entries are the exception: they keep the request only, and a failed read keeps its error message.
- Status: HTTP response status.
- Timestamp: server time of the request.
Read-only operations (GET, HEAD) are not captured. Their volume would swamp the mutation log without adding compliance value. Reads made through the MCP server are the exception, for the reason given in Isolating what an AI assistant did.
What’s redacted
Before storage, ZopDay redacts fields that look like secrets (such as passwords, tokens, and API keys) from request and response bodies, matching on the field name. Environment variable values are never written to the audit trail. A secret in a field whose name doesn’t mark it as one can pass through, so don’t put secrets in oddly named fields.
Bodies are also size-capped. A body over the cap is replaced with a truncation marker, so the audit log never turns into storage for large payloads.
Per-organisation isolation
Audit logs are per organisation. Each organisation’s audit trail is kept separately, and you see only your own organisation’s entries.
View audit logs
Open Activity → Audit Logs in the sidebar. Filter by action, resource, status, user, or date range, and search across users and resources. Expand any entry to see its full request and response body. Failed operations are marked in the description column so you can spot them quickly.
Isolating what an AI assistant did
Every entry records where it came from. The MCP only filter narrows the log to calls made through the MCP server rather than by a person in the app, so you can see exactly what the assistant did, separate from the rest of the trail.
MCP reads are the one exception to the mutations-only rule above. An assistant reading your estate is worth a record, so ZopDay captures those reads too and labels each with the tool that ran. A read entry records the request, not the response. A burst of reads in the same instant collapses into a single entry with a count, so one assistant question doesn’t bury a day of real changes.
Export to CSV
Filter
Set the filters for the entries you want.
Export
Click Export CSV. ZopDay downloads every entry matching the current filters, up to 10,000 rows, as a CSV file. Keep the tab open until the download finishes.
Narrow if capped
If the export hits the 10,000-row cap, ZopDay warns you. Narrow the filters or date range and export again.
Forward to your SIEM
You can forward the audit feed to your SIEM (Splunk, Datadog, Sumo Logic, generic syslog, or object storage). To enable forwarding and configure the destination, contact your account team.
Reference
Common queries
| Question | How to find it |
|---|---|
| ”Who deleted that environment yesterday?” | Filter: Action = Deleted, Resource = Project (environments are logged under their project’s path), date range = yesterday |
| ”What changed in production in the last hour?” | Filter: date range = today, Status = Success, Resource = Deployment |
| ”Did this user have access to do this?” | Filter: User = their email; the request body shows the resource ID; verify the policy in Settings → Roles |
| ”Why did this deploy fail?” | Filter: Status = Failed, Resource = Deployment, date range = around the failure |
| ”What did the IAM import wizard write?” | Filter: Resource = Team, then Role, date range = around the import |
Troubleshooting
My CSV export stopped at 10,000 rows
The export is capped at 10,000 rows. Narrow the filters or date range and export again in parts.
I can't open Audit Logs
Your role lacks audit-log:view. Ask an admin to grant it in Settings → Roles.
A read I made isn't in the log
Reads (GET, HEAD) aren’t captured, except reads made through the MCP server.
An entry's body shows a truncation marker
The body was over the audit size cap, so it was replaced with a marker. Very large payloads, such as big manifests, may not be captured in full.