Activity Records - Security

An audit trail must be trustworthy in two ways: records cannot be changed, and only users with permission can read them.

Records Cannot Be Changed

• The database blocks changes. It rejects changing or deleting a record, for every user, the service included.

• There is no API to change or delete a record.

• The same event is saved once, even when it is sent again.

A database administrator could still turn off the block, or empty the table. That is why it runs on its own server, with its own small group of administrators.

Who Can Read

• Only a signed-in user on the Admin page. There is no API key access.

• Only with the Zitadel role activity.records.read. Admin roles do not include it.

• Gatekeeper also checks the user, if your platform runs it.

• Only their own company. The company comes from the API gateway, not from the request.

A user with the role sees all records of their company, including the input and output of every tool call. These can hold confidential content, like a search query or a document excerpt. Give the role only to the people who need it. Zitadel logs every role change.

Who Can Write

Events come in only through the RabbitMQ queue unique.activity-records.ingest. Intake trusts that queue: it takes the company and the actor from the event. Anyone who can publish to this queue can write records for any company, so only platform services may have access to it.

What Is Stored

Critical data is the extra data of an action. For a tool call, it is the tool's input and output, so it can hold confidential content, like a search query or a document excerpt. It is stored as sent, without filtering, and capped at 1 MiB per event.

Names are saved with the record and are not updated later. For now, records are kept forever.

Redis also holds waiting events, critical data included, and a cache of user names, emails and external ids.

Checklist