Audit

Govern › Audit is the tenant’s record of who changed what, and when. Every sensitive action is written as an entry, and each entry is sealed into a hash chain with the one before it, so a removed, reordered or altered entry is detectable. Admins and auditors read it, verify it and export it.

Who can open it

Role	What they can do
Admin	Read, verify and export the tenant’s trail.
Auditor	Read, verify and export the tenant’s trail.
Builder, End user, Reviewer	Cannot open the page.
Platform admin	Read, verify and export any tenant’s trail.

What is recorded

The families below cover what a tenant does:

Family	Examples of actions
People	tenant.user.invite, tenant.user.role, tenant.user.disable, tenant.user.enable, tenant.user.remove, tenant.user.invitation_resend, tenant.user.temporary_password
Keys and budgets	key.create, key.revoke, budget.update, budget.delete, model_budget.set, model_budget.delete
Models	model.deploy, model.undeploy, llmaas.subscribe, llmaas.unsubscribe
Build	agent.create, agent.update, agent.delete, agent.tools, agent.skills.set, agent.collaborators.set, skill.*, mcp_server.*, collection.*, pipeline.*, vectordb.*
Agents at run time	agent.run, agent.tool, agent.approval.approve, agent.approval.reject
Assistants	assistant.create, assistant.update, assistant.status, assistant.key.mint, assistant.delete
Guardrails	guardrail.policy.update, and one entry per scan with a finding: guardrail.flag, guardrail.redact or guardrail.block
Review	score.recorded, scores.export
Code Assistant and Security	code_assistant.*, security.*
Data subjects	erasure.end_user, erasure.platform_user
The trail itself	audit.export

Each entry holds:

• Time, in UTC.
• Actor: the email of the person who acted, or their sign-in subject when the token carries no email.
• Action: the code, for example key.revoke.
• Object: what was acted on, such as a key ID or a model name.
• IP address: the caller’s address, when known.
• Before and After: what the object looked like on each side of the change, when the action keeps them.

What entries never hold: API key secrets, temporary passwords, and the text a guardrail matched. A guardrail entry records the category, the kind of entity and how many were found, plus any kind of entity the scanner could not look for. An erasure entry names the person by digest, never by their reference.

What you see

1. The header, “A tamper-evident record of who changed what, and when”, with the tenant picker and two buttons: Export CSV and Verify integrity.
2. The result of the last verification or export, when there is one.
3. The Audit trail table: the 200 most recent entries for the tenant, newest first.

Column	What it shows
Time	Date and time.
Actor	Who acted.
Action	The action code, in a tag coloured by family.
Object	What was acted on. It links to the object’s page when that page exists.
Actions	Details, which opens the entry.

Search actor, action, object filters the 200 entries on the page. The search is kept in the address, so a filtered view can be shared.

An entry’s page

Details opens the entry on its own page. The title is the action in words, for example “Tenant user invited”, with the actor and the time under it. Back to the audit trail returns to the list as you left it.

• Overview lists Action, Actor, Object, Time, IP address and Entry (its number in the chain).
• Change shows what the action changed:
  • Changed fields: one row per field that differs, with Field, Before and After. Nested fields are written as a dotted path, such as limits.rpm. A list counts as one field, shown whole on each side. A creation has no before and a deletion no after, so every field appears as added or removed.
  • Before and After: the full record on each side, with a copy button.
  • No change recorded when the action keeps neither side.

An entry of another tenant, or an address that does not exist, shows This audit entry is not here.

What you can do

Verify the trail

1. Choose the tenant.
2. Select Verify integrity.

Olympusx AI walks the tenant’s whole chain and recomputes every seal. The result is one of:

• Audit trail verified — “The hash chain is intact. Entries checked:” followed by the count, and the first 12 characters of the newest seal (the head).
• Tampering detected — the number of the first entry that fails and why: an entry was modified, removed, reordered or never sealed.

Keep the head value from a verification. A later verification whose chain still contains that seal shows that nothing before it changed.

How the chain works

Each entry is sealed with row_hash = SHA-256(prev_hash || entry), where prev_hash is the previous entry’s seal and the entry’s fields (entry number, time, actor, tenant, action, object, before, after and IP address) are encoded in that fixed order, each prefixed with its length. The first entry of a chain is sealed against 32 zero bytes. Each tenant has its own chain. Changing any field of any entry changes its seal and breaks every link after it.

Export the trail

1. Choose the tenant.
2. Select Export CSV.

The file, audit-<tenant>.csv, covers the last 365 days of the tenant’s trail, oldest first. Its columns are:

id,ts,actor,action,object,ip,before_sha256,after_sha256,prev_hash,row_hash

• before_sha256 and after_sha256 are SHA-256 digests of the before and after records.
• The last row starts with TOTAL: the number of entries, then the seal the first exported entry links to (the start anchor) and the seal of the last exported entry.
• A file that ends without the TOTAL row was cut short.
• A window holding more than 200,000 entries is exported up to that number, oldest first, and ends with a TRUNCATED row.

Taking an export is itself recorded, as audit.export.

What an exported file proves

A recipient can check the file without access to Olympusx AI: every row’s prev_hash equals the row_hash of the row before it, and the first row’s prev_hash equals the start anchor in the TOTAL row. If that holds, no entry was removed, inserted or reordered within the window.

Whether entry contents are unchanged is what Verify integrity answers, on the platform. Run both when you hand the trail to an examiner.

Retention

The trail is kept forever unless a platform administrator sets a retention window for audit entries. When old entries are removed, Olympusx AI writes an anchor recording the seal of the last removed entry, and verification starts from that anchor, so the remaining chain still verifies and still detects tampering. Olympusx AI refuses to remove entries if the remaining chain would not verify. See Data retention.

Erasure never deletes audit entries.

Limits

Limit	Value
Entries shown on the page	200 most recent
Export window	Last 365 days
Entries per export file	200,000
Seal	SHA-256, one chain per tenant

Related

• Security model
• Erasure
• Data retention
• Guardrails
• Roles matrix