Audit log

The audit log is a running record of what the platform did with your requests. Every time the platform routes a request, runs it through a guard, or you change a setting like switching a module on, it writes an entry here. You can use it to see what happened and when, to check that things behaved the way you expect, and to keep records for your own compliance.

You will find it under Platform > Audit logs.

What we record, and what we don't

The audit log keeps the details about each event, not the content of your requests. It records things like which part of the platform acted, what it decided, when, and for which request. It does not store your prompts, the model's responses, or any of the data inside them.

This is deliberate. Keeping the content out of the log is part of how the platform protects the personal data in your requests. So the audit log is safe to read, share with a colleague, and export, without exposing the underlying request data.

Reading an entry

Each row is one event. From left to right you will see:

  • Time. When the event happened. Hover to see the exact timestamp.
  • Component. The part of the platform that acted, for example a guard, the router, or your account settings.
  • Action. What it decided or did, for example Allowed, Blocked, Flagged, Enabled or Disabled.
  • Request ID. The identifier of the request the event belongs to. Events that share a request ID are part of the same request.
  • Actor. The person who triggered the event, or System when the platform acted on its own.

Click any row to open a panel with the full details for that event. This is where you see the extra context, such as what a guard found or which module a setting change applied to.

Finding what you need

The newest events show first. To narrow the list, use the controls above the table.

  • Component and Action let you filter to specific kinds of events. You can pick more than one. The options only include values that actually appear in your log, so you will not see a filter for something that never happened.
  • Date filters to a range, which is useful when you are looking into something that happened on a particular day.
  • Search matches on the request ID and on the actor's name. It is not case sensitive, so you do not need to match the capitalisation.

Filters take effect as soon as you choose them, and search runs a moment after you stop typing. The page address updates as you filter, so you can bookmark a filtered view or send the link to a colleague and they will see the same thing.

Exporting

Use the Export CSV button to download the log as a spreadsheet file. The export includes whatever filters and search you have applied, so you get exactly the rows you are looking at rather than the entire log.

The file has one row per event, with the time, component, action, request ID, actor and details. It opens in any spreadsheet program. As with the page itself, the export contains only event details, never the content of your requests.

This is handy for keeping records, for sharing a period of activity with an auditor, or for doing your own analysis outside the platform.

Good to know

Entries do not change. Once an event is recorded it stays as it is. The platform never edits an entry, it only adds new ones, so the log is a reliable history.

Entries are kept for 12 months. After that they are removed automatically. If you need to keep activity for longer, export it with the button above and save the file on your side before it ages out.

Each entry belongs to your organization. You only ever see your own organization's activity.

The log fills in as you use the platform. A new account has little in it. As you send requests and turn on modules, the matching events start to appear.