Audit events catalogue

The platform emits a fixed, enumerated set of audit actions. Free-form action strings are not permitted — every action your SIEM receives is from this catalogue. This guarantees the events are machine-parseable and that the same action means the same thing across customers.

For the audit log's storage model, retention, and forwarding, see Audit logging. For the SIEM wire format, see SIEM forwarding.

Actions by namespace

Secrets

Secret providers

Generic resources

For resources without a dedicated namespace (workflows, knowledge-base documents, managed tables, etc.):

Authorization decisions

These events record denied and granted authorisation decisions for sensitive operations:

Execution grants

Workflow execution grants — the short-lived server-issued tokens that authorise a workflow run. See Authorization.

SCIM provisioning

Integration entitlements

For installed integrations and the hard-fencing setup:

SIEM / audit-log self-events

License

Resource types

The resourceType field on each event identifies what was acted on:

Event payload

Every event carries:

Example payloads

SECRET_ACCESS

{
  "id": "aud_abc123",
  "action": "SECRET_ACCESS",
  "resourceType": "secret",
  "resourceId": "sec_xyz789",
  "actorId": "usr_456",
  "organizationId": "org_001",
  "metadata": { "secretName": "OPENAI_API_KEY", "strategy": "LOCAL" },
  "ipAddress": "10.0.1.42",
  "userAgent": "Mozilla/5.0...",
  "createdAt": "2026-03-16T10:30:00Z"
}

AUTH_EXECUTE_DENIED

{
  "id": "aud_def456",
  "action": "AUTH_EXECUTE_DENIED",
  "resourceType": "workflow",
  "resourceId": "wf_q3report",
  "actorId": "usr_789",
  "organizationId": "org_001",
  "metadata": {
    "policy": "workflow.execute",
    "reason": "actor not a workspace member"
  },
  "ipAddress": "10.0.1.99",
  "userAgent": "PostmanRuntime/7.32.0",
  "createdAt": "2026-03-16T10:31:15Z"
}

INTEGRATION_ENTITLEMENT_SYNC

{
  "id": "aud_ghi789",
  "action": "INTEGRATION_ENTITLEMENT_SYNC",
  "resourceType": "integrationEntitlement",
  "resourceId": "ent_m365_alpha",
  "actorId": "system",
  "organizationId": "org_001",
  "metadata": {
    "provider": "microsoft",
    "scopeId": "<entra-security-group-object-id>",
    "added": 3,
    "removed": 1,
    "unchanged": 12,
    "unmappable": 0
  },
  "ipAddress": null,
  "userAgent": null,
  "createdAt": "2026-03-16T11:00:00Z"
}

What's deliberately not in the log

The catalogue records that something happened, not the data it operated on:

• Secret values are never logged. Secret names and IDs are.
• Knowledge-base document content is never logged. Document IDs and classifications are.
• Workflow input and output payloads are never logged. Workflow IDs, durations, and outcomes are.
• LLM prompt content is never logged. Token counts, model IDs, cost, and the integration source are.
• User passwords are never logged. Sign-in events are.

This separation is what lets the audit log be exposed to auditors without also exposing the underlying data.

Compliance mapping

Vanta automation

Many compliance frameworks ask the same questions ("show me failed logins", "show me access reviews"). The audit-event catalogue is wired into Vanta's evidence collection — see Compliance for which Vanta slots each event family fills.

Related

• Audit logging — storage, retention, query.
• SIEM forwarding — push events to your SIEM in near real-time.
• Compliance — framework mappings.
• Permission model — what generates AUTH_* events.