Internal Schedule API

Internal workflow schedule routes for the discoveries plugin.

Overview

These routes provide the same capabilities as the existing public schedule API in elastic_assistant (/api/attack_discovery/schedules), but with workflow-specific configuration. When the feature flag is enabled, the Attack Discovery UI calls these internal routes instead of the public API.

Key Design Decisions

• Always alerting-backed: Schedules are always alerting rules of type attack-discovery, managed via the AttackDiscoveryScheduleDataClient from @kbn/attack-discovery-schedules-common. This is true regardless of feature flag state — the hybrid architecture ensures the Alerting Framework always owns scheduling, alert persistence, and action execution (with full throttling/frequency support). See the ADR for rationale.
• Asymmetric tag visibility: The internal API applyTags tags every write with attack-discovery-schedule, but it does not apply a read filterTags. As a result the internal API surfaces all schedules — both workflow-tagged schedules and legacy (untagged) schedules created via the public API. The legacy public API is the side that filters: it excludeTags the attack-discovery-schedule tag so it never surfaces workflow schedules. See Why asymmetric visibility? for the rationale.
• Shared infrastructure: Both APIs share the same data client, field maps, and transforms from @kbn/attack-discovery-schedules-common, minimizing duplication.
• snake_case: All request/response parameters use snake_case, matching the OpenAPI schemas in @kbn/discoveries-schemas.

Why asymmetric visibility?

The internal API is the migration surface for the new workflow-scheduling UI, so it must show users all of their existing schedules — including legacy schedules created before the feature flag was enabled. Applying a read filterTags would hide those legacy schedules, breaking migration continuity. The internal API therefore reads unfiltered (superset view) while tagging its own writes.

Cross-API update is safe because the public API's update path reads the existing schedule first and preserves any stored workflowConfig (see elastic_assistant/.../schedules/public/put/update.ts), so updating a workflow schedule through the public API no longer strips its workflowConfig (ESQL queries, custom workflow IDs). The legacy public API still excludeTags workflow schedules from its own reads so it presents only the classic experience.

Feature Flag

feature_flags.overrides:
  securitySolution.attackDiscoveryWorkflowsEnabled: true

The routes gate on this flag via assertWorkflowsEnabled. When it is OFF, these routes return 404 Not Found with { message: 'Attack Discovery workflows are not enabled' }.

Routes

All routes require internal access. Read routes require the securitySolution-attackDiscoveryAll API privilege; mutating routes additionally require securitySolution-updateAttackDiscoverySchedule and alerts-read.

POST /internal/attack_discovery/schedules

Creates a new workflow schedule.

Auth: securitySolution-attackDiscoveryAll + securitySolution-updateAttackDiscoverySchedule + alerts-read

Request body (AttackDiscoveryScheduleCreateProps):

AttackDiscoveryScheduleParams:

AttackDiscoveryApiConfig:

WorkflowConfig (three independent retrieval toggles compose the alert set; at least one must be enabled):

Response: 200 OK with the created schedule object.

GET /internal/attack_discovery/schedules/{id}

Retrieves a single schedule by ID.

Auth: securitySolution-attackDiscoveryAll + alerts-read

Path params: id — schedule ID

Response: 200 OK with the schedule object.

GET /internal/attack_discovery/schedules/_find

Lists schedules with pagination and sorting.

Auth: securitySolution-attackDiscoveryAll + alerts-read

Query params:

Response: 200 OK with { page, per_page, total, data: Schedule[] }.

PUT /internal/attack_discovery/schedules/{id}

Updates an existing schedule.

Auth: securitySolution-attackDiscoveryAll + securitySolution-updateAttackDiscoverySchedule + alerts-read

Path params: id — schedule ID

Request body: Same fields as create (all optional for partial update).

Response: 200 OK with the updated schedule object.

DELETE /internal/attack_discovery/schedules/{id}

Deletes a schedule.

Auth: securitySolution-attackDiscoveryAll + securitySolution-updateAttackDiscoverySchedule + alerts-read

Path params: id — schedule ID

Response: 200 OK with { id }.

POST /internal/attack_discovery/schedules/{id}/_enable

Enables a disabled schedule.

Auth: securitySolution-attackDiscoveryAll + securitySolution-updateAttackDiscoverySchedule + alerts-read

Path params: id — schedule ID

Response: 200 OK with { id }.

POST /internal/attack_discovery/schedules/{id}/_disable

Disables an enabled schedule.

Auth: securitySolution-attackDiscoveryAll + securitySolution-updateAttackDiscoverySchedule + alerts-read

Path params: id — schedule ID

Response: 200 OK with { id }.

Architecture

┌─────────────────────────────────┐     ┌─────────────────────────────────┐
│  Public API (elastic_assistant) │     │  Internal API (discoveries)│
│  /api/attack_discovery/schedules│     │  /internal/.../schedules        │
│  applyTags:  (none)             │     │  applyTags:  attack-discovery-   │
│  excludeTags: attack-discovery- │     │              schedule            │
│               schedule          │     │  filterTags: (none — shows all)  │
│                                 │     │                                  │
└───────────┬─────────────────────┘     └───────────┬─────────────────────┘
            │                                       │
            └──────────────┬────────────────────────┘
                           │
            ┌──────────────▼──────────────────────┐
            │ @kbn/attack-discovery-schedules-common│
            │ - AttackDiscoveryScheduleDataClient   │
            │ - Transforms (API ↔ internal)         │
            │ - Field maps, constants               │
            └──────────────┬──────────────────────┘
                           │
            ┌──────────────▼──────────────────────┐
            │ Kibana Alerting Framework            │
            │ - Rule type: attack-discovery         │
            │ - Task Manager (scheduling)           │
            │ - Alerts-as-data (results)            │
            │ - Actions (notifications)             │
            └──────────────────────────────────────┘

Route Differences from Public API

Both APIs use the same AttackDiscoveryScheduleDataClient (alerting-backed). The internal API adds workflow_config support so the executor can delegate generation to the workflows engine while the Alerting Framework retains ownership of scheduling and action execution.

Relationship to Public API

The internal API is additive — it does not modify or replace the public API. Both APIs coexist, creating alerting rules of the same type but isolated by tags. The public API's FTR tests continue to pass unchanged.

When the feature flag is disabled, the UI falls back to the public API, ensuring zero disruption for users who have not opted into the new scheduling.

Testing

Scout API integration tests are located at:

discoveries/test/scout/api/tests/

See the test README for instructions.