Connect Your AI Agent with Elastic Security for Slack

Set the workflow status of one or more Elastic Security alerts (signals) by ID via POST /api/detection_engine/signals/status. Run Search Alerts first to obtain signal IDs. Example: calling with alertStatus: "closed", signalIds: ["abc123"], reason: "false_positive" returns { updated: 1, version_conflicts: 0 }. See the documentation

Search Elastic Security detection alerts (signals) via POST /api/detection_engine/signals/search using raw Elasticsearch Query DSL. Use this to find alert IDs before running Update Alert Status, or to investigate alert volume/details for a case. Returns the raw Elasticsearch search response with a hits.hits array; each hit's _id is the signal ID and _source holds the alert's full ECS document. Example: calling with query: {"bool":{"filter":[{"term":{"kibana.alert.workflow_status":"open"}}]}} and size: 5 returns { hits: { total: { value: 12 }, hits: [{ _id: "abc123", _source: { "@timestamp": "...", "kibana.alert.workflow_status": "open", "host.name": "..." } }, ...] } }. Omit query to match all alerts. _source always holds the full ECS document; use fields to additionally get a compact, array-valued view of just the fields you need (under each hit's fields key) without parsing the full document yourself. See the documentation

Manually run one or more Elastic Security detection rules over a time range via POST /api/detection_engine/rules/_bulk_action (bulk action run). Use this to test a rule immediately instead of waiting for its next scheduled interval, or to backfill detections over a past window. Provide the rule ids to execute. Run Find Detection Rules first to obtain valid ids. Defaults to roughly the last hour if not specified: endDate defaults to one minute ago (a small buffer so clock skew/latency can't push it into the future, which Kibana rejects), and startDate defaults to one hour before that. Note: Kibana rejects manual runs against disabled rules — the rule must have enabled: true (see Create or Update Detection Rule). Example: calling with ids: ["7ac3..."] and no dates returns { attributes: { results: { created: [{ id: "7ac3...", name: "..." }] }, summary: { succeeded: 1, failed: 0 } } }. See the documentation

List all unique tags currently in use across Elastic Security cases via GET /api/cases/tags, or detection rules via GET /api/detection_engine/tags. Use this before tagging a case or rule so you reuse an existing tag instead of creating a near-duplicate (e.g. incident-response vs. incident_response). Cross-referenced by the tags parameter on Create or Update Case, Create or Update Detection Rule, and Find Cases. Example: calling with objectType: "case" returns ["council-jurassic-eval", "ransomware", "insider-threat"]. See the case tags documentation and the rule tags documentation

Find and list Elastic Security detection rules via GET /api/detection_engine/rules/_find, or fetch a single rule directly via GET /api/detection_engine/rules when id or ruleId is provided. Use this to search/browse rules, or to look up one rule's full definition once you have an ID. Run this first to obtain an id/ruleId before using Create or Update Detection Rule, Run Detection Rule, or Delete Record. Example: calling with filter: 'alert.attributes.enabled: true' returns { total: 3, data: [{ id: "7ac3...", name: "InGen Perimeter Query Rule", type: "query", enabled: true, ... }] }; use fields to shrink each rule down to just the fields you need — rule objects carry many advanced fields (exceptions_list, related_integrations, threat, etc.) that are rarely relevant. See the documentation

Find and list Elastic Security cases via GET /api/cases/_find, or fetch a single case directly via GET /api/cases/{caseId} when caseId is provided. Use this to search/browse cases, or to look up one case's full details (including its version token) once you have an ID. Run this first to obtain a caseId before using Create or Update Case, Add Case Comment, or Delete Record. Example: calling with search: "perimeter breach" and status: "open" returns { total: 1, cases: [{ id: "a1c1...", title: "Isla Nublar Perimeter Breach", severity: "high", status: "open", ... }] }; use fields to shrink each case down to just the fields you need. See the documentation

List users who have created or reported Elastic Security cases, via GET /api/cases/reporters, to discover valid profile_uid values for the assignees parameter on Create or Update Case. Kibana has no public endpoint for listing every org user or for listing who is eligible for assignment — this endpoint only covers people who have reported at least one case, which is a subset of valid assignees, not the full set. If the person you need doesn't appear here (e.g. they've never reported a case), ask the user for their profile_uid directly instead of guessing. Example: calling with no parameters returns [{ username: "jsmith", full_name: "Jane Smith", email: "[email protected]", profile_uid: "u_abc123_cloud" }]; pass that profile_uid as an entry in Create or Update Case's assignees array. See the documentation

Permanently delete an Elastic Security case or detection rule by ID. Cases are deleted via DELETE /api/cases; detection rules via DELETE /api/detection_engine/rules. Run Find Cases or Find Detection Rules first to obtain a valid ID for the object you want to delete. Example: calling with objectType: "case" and recordId: "a1c1..." returns { success: true, objectType: "case", recordId: "a1c1..." }. This is destructive and cannot be undone. See the delete case documentation and the delete rule documentation

Create a new Elastic Security detection rule via POST /api/detection_engine/rules, or full-replace update an existing one when id is provided, via PUT /api/detection_engine/rules. On update, the tool first fetches the rule's current definition and merges your supplied fields into it, so you only need to pass the fields you want to change — Kibana's underlying PUT still requires the full definition, but this tool handles that for you. Run Find Detection Rules first to obtain the id for updates (it also accepts ruleId if that's all you have). name, description, riskScore, severity, and type are required when creating (no id); optionally set ruleId on create to assign a custom rule_id instead of letting Kibana generate one. For type: threshold rules, set threshold. For type: threat_match rules, set threatIndex and threatMapping. Use additionalFields as an escape hatch for any other type-specific fields (e.g. anomaly_threshold for machine_learning rules). Example: calling with name: "Suspicious PowerShell", description: "...", riskScore: 60, severity: "high", type: "query", query: "process.name: powershell.exe" returns { id: "7ac3...", rule_id: "f3bb...", name: "Suspicious PowerShell", enabled: true, ... }; calling again with that id and riskScore: 80 returns the same rule with only the risk score changed. See the create documentation and the update documentation

Create a new Elastic Security case, or update an existing one when caseId is provided, via POST /api/cases or PATCH /api/cases. Use this to open a new case, or to edit a case's title, description, severity, tags, category, assignees, or status. When caseId is provided, the tool fetches the case's current version internally before updating — never guess or supply a version yourself. Run Find Cases first to obtain a caseId for updates. Use Add Case Comment to attach comments instead of this tool. title and description are required when creating (no caseId). Example: calling with title: "Perimeter Breach", description: "...", severity: "high" returns { id: "a1c1...", title: "Perimeter Breach", status: "open", version: "Wzc1LDFd", ... }; calling again with that caseId and status: "closed" returns the same case updated. See the create documentation and the update documentation

Add a user comment to an Elastic Security case via POST /api/cases/{caseId}/comments. Use this to log investigation notes or updates on a case without changing its status or fields — use Create or Update Case for that. Run Find Cases first to obtain a valid case ID. Example: calling with caseId: "a1c1..." and comment: "Confirmed unauthorized access via badge logs." returns the updated case object with totalComment incremented and the new comment in comments. See the documentation