Audit log events
The audit log captures a structured record of every state-modifying administrative action on the platform. Each entry is immutable, cannot be edited or deleted by any user, and supports compliance frameworks such as SOC 2 and ISO 27001. This page documents the event schema: the fields present on every event, the event vocabulary, and the resource-specific details payloads. For the surface that browses the log, see Audit Logs. For the operator-side workflow that combines the audit log with usage analytics, see Audit Platform Activity.
Event envelope
Every audit event carries the same envelope of fields, regardless of which administrative action produced it.
| Field | Type | Description |
|---|---|---|
timestamp | string (RFC 3339, UTC) | The exact moment the action was recorded |
actor | object | The user that performed the action |
actor.email | string | The actor's email address as known to the platform |
actor.role | string | The actor's Agent Router role at the time of the action |
action | string | The event type, in <resource>.<verb> form |
resource | object | The resource the action affected |
resource.type | string | The resource family (model, provider, user, api_key, and so on) |
resource.id | string | A stable identifier for the resource |
resource.display_name | string | A human-readable label for the resource |
details | object | Resource-specific payload describing what changed |
request_id | string | The internal request ID for the administrative call that produced the event. Useful for joining the audit log to other internal telemetry |
The actor, action, and resource fields together answer the who, what, and to which thing questions. The details payload carries the how: old and new values for changes, full configuration for creations, and additional context where relevant.
Event types
Events are named in the <resource>.<verb> form. The verbs are consistent across resources: created, updated, deleted, enabled, disabled, and a small set of resource-specific verbs where the lifecycle differs.
Models
| Action | Generated when |
|---|---|
model.enabled | A model is enabled for Console users in Models Management |
model.disabled | A model is disabled and removed from the Console catalogue |
The details payload for model events includes the model identifier, the provider, and the prior status if applicable.
Providers
| Action | Generated when |
|---|---|
provider.created | A new provider configuration is added in Providers Management |
provider.updated | An existing provider's configuration is edited: credentials, endpoint URL, or other fields |
provider.deleted | A provider configuration is removed |
The details payload includes the changed field names, the old and new values where applicable, and the connection status reported by the provider after the change. Credential values are not included in the payload; their presence or absence is recorded but the values themselves are never written to the audit log.
Users
| Action | Generated when |
|---|---|
user.role_changed | A user's role is modified, whether through manual edit or through SSO claim mapping |
user.status_changed | A user's Active or Inactive status changes |
The details payload includes the user's email, the prior role, the new role, and the source of the change (manual or sso_mapping). For SSO-driven changes, the actor field reflects the user themselves rather than an administrator, because the change was triggered by the user's own login.
API keys
| Action | Generated when |
|---|---|
api_key.created | A new API key is issued, whether from the Console (self-service) or from the Admin Dashboard |
api_key.revoked | An API key is revoked, whether from the Console or from the Admin Dashboard |
api_key.configuration_changed | A key's routing configuration or rate limit settings are modified |
The details payload includes the key's name, the owner's email, the key prefix (the first characters of the key value, never the full value), and the source of the change. For revocations performed from the Admin Dashboard, the actor differs from the key owner; for self-service revocations, the actor and the owner are the same.
Announcements
| Action | Generated when |
|---|---|
announcement.created | An announcement is published |
announcement.updated | An existing announcement is edited |
announcement.archived | An announcement is archived and removed from the Console |
announcement.restored | An archived announcement is restored to active status |
The details payload includes the announcement title, the severity, and a diff of the body where the announcement was edited.
SSO configuration
| Action | Generated when |
|---|---|
sso.configured | The SSO protocol or its configuration values change |
sso.enabled | The Enable SSO toggle is switched on |
sso.disabled | The Enable SSO toggle is switched off |
The details payload includes the protocol (saml or oidc) and the fields that changed. Client secrets and signing certificate contents are not included; only the presence of a change is recorded.
MCP catalogue
| Action | Generated when |
|---|---|
mcp_server.created | An MCP server is added to the catalogue |
mcp_server.updated | An existing MCP server's configuration is edited |
mcp_server.deleted | An MCP server is removed from the catalogue |
mcp_oauth_client.created | A new OAuth client is added in MCP OAuth Clients |
mcp_oauth_client.updated | An OAuth client's configuration is edited |
mcp_oauth_client.deleted | An OAuth client is removed |
The details payload includes the server or client name, the changed fields, and the authentication type for MCP server events. OAuth client secrets are not included in the payload.
Instances and settings
| Action | Generated when |
|---|---|
instance.configuration_changed | An editable instance-level setting is modified on the Instances surface |
settings.changed | Any other instance-scoped settings change |
The details payload includes the field name and the old and new values.
Example event
{
"timestamp": "2026-05-28T14:32:18Z",
"actor": {
"role": "model_admin"
},
"action": "model.disabled",
"resource": {
"type": "model",
"id": "gpt-4o",
"display_name": "gpt-4o"
},
"details": {
"provider": "openai",
"prior_status": "enabled",
"reason": null
},
"request_id": "8f14e45f-ceea-467f-a8f0-6b2a1c3d4e5f"
}
Coverage and immutability
Two properties of the audit log are worth asserting for compliance and integrity purposes.
- Coverage. Every state-modifying administrative action generates an audit event. There is no path through the Admin Dashboard that changes platform state without leaving a record. SSO-driven role assignments are captured under the same vocabulary as manual edits, so directory-driven changes are not invisible.
- Immutability. Audit entries cannot be edited or deleted by any user, regardless of role. There is no "delete from the log" operation anywhere in the platform.
Retention is configured per deployment. For long-horizon retention beyond the in-platform window, export the audit stream to an external SIEM or log store; the OTel-based observability pipeline supports the same dimensions used in the in-Console audit surface.
Related
- Audit Logs, the surface for browsing audit events
- Audit Platform Activity, operator workflow combining the audit log with usage analytics
- OTel Metrics, metric stream that complements the audit stream
Where to go next