Skip to main content
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.

​
Why a request went where it did

A router event also records the targets it did not use, and why. If a request named several models, or resolved an alias, the event lists each one that was dropped with its reason: This is what makes enforcement evidenceable rather than merely real. When a model is disabled or an external route refused, the log shows the decision instead of leaving a silent absence. Only slugs and reasons are recorded, never any part of the request’s content. A request that reaches no usable target is not served at all, so it has no router event to carry those reasons. It gets its own entry instead, with the action Refused, naming the model you asked for and the reason each candidate was dropped. That is the entry to look for when you need to show that a request was blocked rather than quietly rerouted: filter the Action column to Refused to see every request the platform turned away and why.

​
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. How long entries are kept depends on your plan. Free and Pay as you go keep 14 days, Team keeps 90 days, Business keeps 365 days, and Enterprise keeps 730 days. 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 services, the matching events start to appear.