Logs and audit

There are two log views with two different jobs. One answers the question of what the system did, meaning which requests ran and what they cost. The other answers the question of who changed something and who accessed which data.

Usage log

Here you find every single request to the model with its point in time, model, provider, person, tokens and cost, plus a few technical figures on the quality of the answer. The requests of one conversation can be viewed bundled together. The view can be filtered and sorted, and what is displayed filtered can be exported as CSV exactly that way.

No conversation content

Only the identifier of a conversation is displayed, never its title and never its content. That is a deliberate data protection decision: the admin view is meant to show what something cost, not what somebody wrote about.

Next to it there is a view for technical errors and a diagnostics view for troubleshooting connectors.

Change history and connector record

The second view logs every modifying action in the panel, so everything that creates, changes or deletes, including the point in time, the person acting, the target affected and the result. For an entry the state before and after can be compared. Sign-ins are included, failed ones too.

Also recorded is every tool call through a connector, with the decision and the reason which rule permitted or denied it. That makes it traceable why an access came about, and not just that it did. Both trails can be exported as CSV.

Secrets are redacted

If you change an access key, the log states that the key with this name was changed, never the value. Values that look like a secret are replaced by a placeholder. An export is therefore safe even when the recipient must not see any keys.

How long the entries are kept is something you define in your deletion policy, see Data protection and retention.

What you need this for

Duty of proof. When somebody asks who changed which setting when, or who accessed which data from a connected system, that cannot be answered without a log. This applies in particular to connectors running in service account mode.

Troubleshooting. When somebody reports “the tool does not answer”, the views separate the cases cleanly: a refused call is a decision and appears in the audit, a technical error appears in the diagnostics. That saves guesswork.

Cost analysis. The usage log shows which model, which person and which kind of conversation is driving usage. A filtered view plus CSV export is usually enough to answer the question “why was last month more expensive”. The aggregated view for that is under Usage, budgets and billing.