Audit event category references

Copy link

Automation orchestrator organizes detailed event type information by security domain. The following three subtopics document the specific event actions, severity levels, and structured data fields for each category of security event:

• Authentication audit events — login attempts, session lifecycle, account management, and authorization denied events.
• Authorization audit events — role assignment and role lifecycle events.
• Service account audit events — service account lifecycle and credential events.

Event categories

Copy link

Automation orchestrator classifies each audit event into one of the following nine categories. Each category maps to an audit source and is stored accordingly. Nine categories are supported at GA 2026-8:

Audit event sources

Copy link

The audit.event_source field identifies how an event was generated. Three event sources are supported at GA:

• business_event — emitted by application-level instrumentation. Reflects platform activity: user actions, agent execution, and settings changes. business_event records are stored in the platform PostgreSQL database and visible in the Audit UI. Use this source for compliance and security monitoring.
• security_event — emitted for security-relevant operations: authentication outcomes, authorization decisions, session lifecycle, and role assignments. security_event records are stored in the platform PostgreSQL database and visible in the Audit UI.
• crud_event — generated by database triggers that automatically record all create, update, and delete operations on audited tables. At GA, crud_event data is forwarded to the OTLP channel only. It does not appear in the Audit UI and cannot be exported through the REST API.

For most compliance use cases, business_event and security_event records provide the most actionable signal. Filter to crud_event only when you need a complete low-level database change trail in your external observability backend.

Severity levels

Copy link

Automation orchestrator assigns severity automatically based on the outcome of the operation. Four severity levels are used at GA:

Actor types

Copy link

Each audit event identifies who performed the action using one of the following three actor types:

• User — a human user authenticated to the platform.
• System — an internal automated process (for example, a background worker or scheduler).
• Service — an internal service or service account acting on behalf of an external system.

Common event fields

Copy link

All audit events contain the following 13 fields. Fields marked as conditional are present only on specific event types.

Resource URN formats

Copy link

The resource_urn field follows the format urn:syntara:resource_type:identifier. Fourteen resource types are supported at GA:

When a resource is hard-deleted from the platform, audit events that reference it retain the resource_urn value in the event record. The resource itself is unrecoverable through the platform API or UI. Audit events are the only remaining record of the deleted resource's history.

Per-event structured data schemas

Copy link

In addition to the common fields, certain event categories include extra structured data fields that provide context specific to that event type. These fields appear in the structured_data object on the event record.

LLM interaction events

Include the following additional fields:

• actor — identifier of the agent or service that initiated the LLM call.
• model — name of the LLM model used.
• input_tokens — number of tokens in the request.
• output_tokens — number of tokens in the response.
• latency_ms — latency of the LLM API call in milliseconds.
• workflow_instance_id — workflow execution run identifier.
• invocation_id — agent execution correlation identifier.

Note

Full LLM prompt and response content is intentionally excluded. Only metadata is recorded to maintain a privacy boundary for user-submitted input.

LLM tool call events

Include the following additional fields:

• tool_name — name of the tool invoked by the LLM.
• tool_call_id — unique identifier for this specific tool call, matching the tool call ID in the LLM API response.
• outcome — result of the tool call: success, error, or auth_failure. An auth_failure outcome corresponds to a SEC-402 security event indicating an unauthorized tool access attempt.
• invocation_id — agent execution correlation identifier.
• workflow_instance_id — workflow execution run identifier.

LLM reasoning events

Include the following additional fields:

• step_type — type of reasoning step: think, tool_selection, response_generation, or reflection.
• step_sequence — integer position of this step within the current agent invocation's reasoning loop.
• decision_outcome — the decision reached at this step: tool_invoked, response_returned, or loop_continued.
• invocation_id — agent execution correlation identifier.
• workflow_instance_id — workflow execution run identifier.

Note

Reasoning text and chain-of-thought content are intentionally excluded from LLM reasoning events. Only the step type, position, and decision outcome are recorded.

Workflow lifecycle events

Include the following additional fields:

• workflow_instance_id — unique identifier for the workflow run.
• workflow_id — identifier of the workflow definition.
• run_status — final run status: completed, failed, or cancelled.
• failure_reason — present when run_status is failed.

Security events

Security events may include these additional fields depending on the event action:

• auth_method — authentication method used (for login events).
• token_version — version of the token presented (for stale token events).
• current_version — current required token version (for stale token events).
• sessions_revoked — count of sessions invalidated (for revocation events).
• role_id — identifier of the role assigned or revoked.
• assignee_id — identifier of the user, group, or service account receiving a role change.