Auditability

An auditor asks two kinds of question: what happened, and how you know the record of it is complete and unchanged. Catalyst keeps four records that between them cover your organization, your regions, your IDs and your workflows. Three of them can be signed where they are written, so you can check them yourself without trusting Diagrid or the systems that store them. Signing is off by default: each region turns on its audit log and its App IDs' API log signing, and each project turns on workflow history signing.

The four records

Record	Answers	Written by	How you check it
Control-plane audit log	Who changed what in your organization: projects, IDs, components, API keys, secrets.	The Catalyst control plane	Integrity checked by Diagrid
Region audit log	Who called a region's API, and with what result: starting, terminating or rerunning a workflow, reading its history.	Each region	Signed by the region; you verify it
API log	What an ID did through the Dapr APIs: state, pub/sub, service invocation, LLM calls, workflow calls, and what was delivered to it.	Each ID	Signed by the ID; you verify it
Workflow history	What a workflow executed, step by step, with every input and output.	Each ID that runs workflows	Signed by the ID on projects with signing enabled; you verify it

Where each record is writtenThe control plane records changes to your organization. Each region signs a record of calls to its API, and each ID signs its API log and, when enabled, its workflow history.

Control-plane audit log

Every authenticated call to the Catalyst control plane is recorded, whether it came from the console, the CLI or the API: who made it, the resource and action, the caller's address and client, and whether it succeeded. A call that presented a credential that was then rejected is recorded as well.

Organization admins can read it on the Audit log page in the console, or with diagrid audit list. It covers the last three days. Diagrid checks its integrity, and each event shows the result in the Integrity column. You can't verify this record independently. For that, use the region audit log, the API logs and workflow history.

Region audit log

When its audit log is turned on, each region signs a record of every authenticated call to its API, through the console, the CLI or your own automation. Workflow operations such as start, terminate, pause, rerun and purge go through the region API, so this is the record of who did them. Each record holds:

• the caller, taken from the credential the call authenticated with, never from a header the caller sets;
• the method, route, path and project, and the response status;
• the error, for a call that failed, including calls refused for lack of permission;
• how the caller authenticated, their address and their client.

List the calls with diagrid audit list --region, and verify the log with diagrid audit verify. Reading it needs the same permission as the control-plane audit log.

API log

Each App, Agent and MCP server signs its API log: one line per Dapr API call it made or received, with the API, the component, the status, the latency and the trace ID. Signing is turned on per region; see Turn on signing. Verify an App ID's log with diagrid app logs <app> --verify.

Workflow history

On a project created with signing enabled, each ID signs its workflows' history as it runs, so every step, input and output is part of the signed record. See Verifiable execution.

How signing works

The region and each ID sign their logs with their own SPIFFE identity, the same identity that signs workflow history. Every few seconds, and when it stops cleanly, the writer adds a signature covering the lines since the last one. Each signature also links to the one before it and names your organization.

That lets you prove, for any window of the log:

• each line was written by the ID or region named in its signature;
• no line has changed since it was written;
• no line is missing from inside a signed range, and none was moved in from another organization's log.

You verify against the signing authorities your regions publish. These are the same authorities that workflow archives verify against, and diagrid workflow archive trust-anchor saves them to a file. Nothing you verify against comes from the log itself.

Putting the records together

Say an auditor asks about a payment a workflow released on 29 October. The records answer it in layers:

1. What the workflow did. Export the execution as a signed archive. It shows each step, with the inputs and outputs that led to the release.
2. What the ID called. Verify the ID's API log for the same window. It shows the state reads, service calls and LLM calls behind those steps.
3. Who acted on the workflow. Verify the region audit log. It shows who started, paused or reran the instance, from which client, and with what result.
4. Who changed the setup around it. Read the control-plane audit log for changes to the project, the ID, its components or its secrets.

The records don't share an ID. Match them by time, project, ID and workflow instance ID, which appears in the paths of the region audit log and the API log.

To keep the evidence, save each record as you verify it, together with the signing authorities. See Verify API logs and the region audit log and Verify workflow history. The region audit log and the API logs can be read back for up to 7 days, and saved files verify offline at any time after that.

What signing doesn't prove

• That what was written is true. A signature proves which ID or region wrote a line, not that the call happened as described.
• That nothing is missing from either end. Deleting the last lines of a log, a whole run of an ID, or the start of the window you read, signatures included, leaves nothing to compare against. The verify commands print the time the verified records cover, so a window that starts later than you asked for shows.
• Confidentiality. Signed logs are readable by anyone who can read the logs. Signing does not encrypt them.

See also

• Verify API logs and the region audit log: verify, save and check the logs offline.
• Verify workflow history: verify executions and export signed archives.
• Verifiable execution: how workflow history signing works.
• Security: identity, isolation and access control.
• Manage access: roles, including who can read audit logs.