Security events
The audit event stream emitted by every agent and workflow, event naming conventions, notable event types, and the Events screen.
Every deployed agent emits audit events as it runs: session lifecycle, tool executions, network egress decisions, LLM calls, guardrail checks, and quota denials. Workflow executions emit their own lifecycle events alongside the events of every agent they dispatch. Build-time policy checks emit events too, so a policy violation caught before deployment shows up in the same stream as one caught at runtime. All of it lands in one unified event store with one query path — the Events screen under Security → Events.
Anatomy of an event
Every event carries a common envelope plus an event-type-specific payload:
event_type— what happened, named<entity>_<verb>(see below).tsand a producerseq— emit time plus a per-producer sequence number. Timelines order by wall-clock time and useseqto break ties within the same second.- Identity and correlation — org, workspace, the emitting entity
(
entity_typeofagent,workflow, orassistantplusentity_id), the invocation (one agent task) and, for workflow runs, the execution that groups every agent's events for the run. outcome— one ofok,allowed,denied,blocked,masked,modified,cancelled,error, orinfo. Lifecycle events that carry no allow/deny semantic resolve toinfo.severity—info,warning,blocking, orcritical.fields— the event-type-specific detail (for example, anllm_callcarries model, provider, and token counts; anegress_blockedcarries the blocked domain and the rule that matched).
Event naming
Event types follow the <entity>_<verb> convention: the prefix names the
entity or gate, the verb names what happened. Examples: tool_exec,
egress_blocked, guardrail_check, workflow_started,
task_admission_denied. The
prefix is meaningful — it encodes the altitude of the gate. task_admission_denied
is a per-task admission decision, distinct from per-tool or per-LLM-call gates
that may sit alongside it. The runtime's vocabulary grows over time; the
platform accepts and stores well-formed new types, and the console falls back
to the raw type name as the label until a friendly one exists.
Notable event types
| Event type | Meaning |
|---|---|
session_start / session_end | An agent session opened / closed. |
invocation_complete / invocation_cancelled | An agent task finished / was cancelled. |
tool_exec | A tool call started or returned (start and end phases). |
llm_call / llm_call_cancelled | A model call returned / was cancelled. Carries model, provider, and input/output token counts. |
egress_allowed / egress_blocked | An outbound network request was permitted / denied by the egress policy. |
guardrail_check | A guardrail evaluated content; the decision (allowed, masked, blocked) becomes the outcome. |
channel_denied_by_policy | A channel was refused by the effective policy. |
policy_violation_at_build_time | A build-time policy check (egress, tools, channels) rejected an agent configuration. |
task_admission_denied | A task was refused by a token quota. Fields carry scope, window, reason, reset_at, and cached (whether the deny was replayed from the runtime's local cache). |
auth_verify / auth_fail | Inbound agent authentication succeeded / failed. |
auth_step_up_required | A step-up authentication demand was raised. |
credential_issued / credential_revoked / credential_failed | Credential lifecycle (metadata only — never the credential material). |
intent_alignment / intent_drift | Intent alignment checks and detected drift. |
task_deferred / task_deferred_decision / task_deferred_timeout | Deferred-task lifecycle. |
context_compressed / context_expanded / context_pattern_suggested | Context-compression telemetry, including tokens saved per compression. |
policy_loaded / agent_card_published / audit_export_status | Runtime lifecycle and audit-sink health (informational). |
workflow_started / workflow_step_started / workflow_step_completed / workflow_step_failed / workflow_complete / workflow_cancelled | Workflow execution lifecycle, emitted with entity_type workflow. |
By default the Events screen filters to the security-relevant subset —
egress_blocked, policy_violation_at_build_time, channel_denied_by_policy,
guardrail_check, auth_fail, and task_admission_denied — so you see
enforcement signal rather than the full operational firehose. The filter is
adjustable when you need the rest.
The Events screen
Security → Events shows the stream scoped to your selected workspaces, defaulting to the last 24 hours and the security-relevant event types.
- Filtering — by event type, outcome, agent, time range, and workspace scope. A search box matches rule keys, domains, and tool names — this is also where deep links from the Posture screen land, pre-seeded with the rule you clicked.
- Spike detection — a banner flags time buckets where event volume spikes well above baseline, so bursts of denials stand out before you scroll.
- Grouping by run — contiguous events from the same run are grouped, so a single invocation reads as one collapsible unit instead of interleaved rows.
- Event detail — selecting a row opens a drawer with the full envelope and the event-type-specific fields, including the decision that was made and the policy attribution behind it.
Pivoting to a full run
From any event you can pivot to everything correlated with it:
- Invocation timeline — every event from one agent invocation, in order.
- Execution timeline — every event from every agent in one workflow execution, ordered by wall-clock time with the producer sequence breaking ties within the same second. This is the investigator's pivot from a single suspicious event to "what else happened in that run" without leaving the security console.
The same event stream also powers the Activity tab on each agent's detail page, so builders and security reviewers look at the same records.