Attack Discovery Workflows Telemetry

Event-Based Telemetry (EBT) events emitted by the discoveries plugin for the Attack Discovery 2.0 Workflows feature.

For system context (the four entry points, security surfaces, where these events are emitted from), see the canonical discoveries plugin README.

Privacy contract

No event field may carry: query content, alert content, alert rule names, user-defined workflow names, user identifiers, connector credentials. Aside from the diagnostic free-text fields called out below, fields are enums, counts, durations, booleans, and IDs (UUIDs / connector IDs / workflow IDs).

Free-text handling on the failure paths differs by event and is not uniform:

• attack_discovery_step_failure carries no free text — the error is reduced to the bounded error_category enum (plus IDs, counts, and a duration). This is the fully sanitized failure signal.
• attack_discovery_error carries errorMessage, the raw error message (a legacy field shared with elastic_assistant). It is system-generated error text, and can include stack-trace-derived detail from underlying failures.
• attack_discovery_misconfiguration carries detail, a human-readable description of the failed pre-execution check (e.g. which check failed and why).

errorMessage and detail are diagnostic strings intended for root-cause analysis. They must never be constructed from query/alert content, rule or workflow display names, or credentials, but they are not otherwise redacted. When a fully sanitized failure signal is required, use attack_discovery_step_failure.error_category.

EBT event flow

graph TD
  A[Workflow runs] --> B{outcome}
  B -->|success| C[reportWorkflowSuccess]
  B -->|error| D[reportWorkflowError]
  A --> E[Step failure]
  E --> F[reportStepFailure]
  A --> G[Misconfig detected]
  G --> H[reportMisconfiguration]
  I[Schedule action] --> J[reportScheduleAction]
  C --> K[attack_discovery_success]
  D --> L[attack_discovery_error]
  F --> M[attack_discovery_step_failure]
  H --> N[attack_discovery_misconfiguration]
  J --> O[attack_discovery_schedule_action]
  K --> P[core.analytics]
  L --> P
  M --> P
  N --> P
  O --> P

Field Naming Convention

All new EBT fields must use snake_case, consistent with broader Kibana EBT conventions (Agent Builder, Observability, Data/Search, Fleet, etc.).

The attack_discovery_success and attack_discovery_error events are shared with the elastic_assistant plugin, which originally defined them with camelCase field names. Those camelCase fields are retained as-is to avoid breaking the shared event schema. They are marked (legacy) in the tables below.

All three events owned exclusively by discoveries — attack_discovery_schedule_action, attack_discovery_misconfiguration, and attack_discovery_step_failure — already use snake_case exclusively.

Distinguishing Legacy vs Workflow Execution

The attack_discovery_success and attack_discovery_error event types are shared with the elastic_assistant plugin (the legacy path). Events from each path are distinguishable via the execution_mode field:

Additionally, the three events owned exclusively by discoveries (attack_discovery_schedule_action, attack_discovery_misconfiguration, attack_discovery_step_failure) are only emitted when the workflows feature is active.

User Action Events

These events record discrete user actions in the UI. Each maps 1:1 to a button click or API call the user explicitly performed.

attack_discovery_schedule_action

Emitted after a successful schedule lifecycle operation.

Execution Insight Events

These events provide deeper observability into the Attack Discovery generation pipeline. They are emitted automatically during workflow execution, not in direct response to a single user click.

attack_discovery_success

Emitted after a successful generation workflow execution. This event type is registered by elastic_assistant; discoveries reports to the same stream with workflow-specific fields populated.

attack_discovery_error

Emitted when the generation workflow fails. Augmented with step-failure and misconfiguration context to support root cause analysis.

errorMessage carries the raw error text (see Privacy contract).

attack_discovery_misconfiguration

Emitted when a misconfiguration is detected that prevents or degrades Attack Discovery execution. Provides fleet-wide visibility into configuration problems.

misconfiguration_type values:

attack_discovery_step_failure

Emitted when an individual pipeline step fails during generation. Provides per-step failure visibility for fleet-wide debugging.

step values: alert_retrieval, generation, validation

error_category values: the full 16-value enum, produced by classifyErrorCategory — see the error_category enum reference below for the complete table.

Architecture

• Event definitions: event_based_telemetry.ts defines EventTypeOpts<T> objects for each event type.
• Registration: Three events are registered in plugin.ts via core.analytics.registerEventType(): attack_discovery_misconfiguration, attack_discovery_schedule_action, and attack_discovery_step_failure. The shared attack_discovery_success and attack_discovery_error types are registered by elastic_assistant.
• Reporting helpers: Dedicated modules wrap each event type:
  • report_workflow_telemetry.ts — reportWorkflowSuccess / reportWorkflowError
  • report_schedule_action/ — reportScheduleAction
  • report_misconfiguration/ — reportMisconfiguration
  • report_step_failure/ — reportStepFailure (includes classifyErrorCategory heuristic)
• Pipeline metadata: PipelineStepError in run_manual_orchestration/helpers/pipeline_step_error/ carries step-failure metadata from orchestration to the top-level error handler.

Trigger Sources

Product Questions Answered

error_category enum reference

error_category on attack_discovery_step_failure is produced by classifyErrorCategory (see report_step_failure/) which maps an error to one of the bounded values below — either directly from an AttackDiscoveryError.errorCategory, or heuristically from the error message. The raw error message is not retained on the event. The canonical enum lives in @kbn/discoveries-schemas (ERROR_CATEGORIES); the rules are ordered so more-specific patterns win over generic ones.

If a new failure mode warrants its own category, extend ERROR_CATEGORIES in @kbn/discoveries-schemas, add a rule to classifyErrorCategory, and update this table.

FAQ

Why are some fields camelCase? attack_discovery_success and attack_discovery_error are shared with elastic_assistant's legacy path. Their pre-existing fields are camelCase and must not be renamed (would break the schema). All new fields on these events and all fields on the three discoveries-owned events are snake_case.

How are discoveries-owned events distinguished from legacy events? Via execution_mode: 'workflow' on attack_discovery_success/error (legacy never sets this field). The three discoveries-owned events (attack_discovery_misconfiguration, attack_discovery_step_failure, attack_discovery_schedule_action) are only emitted on the workflow path, so their presence is itself a signal.