Elastic IR Agent — Adversarial Verification
for Autonomous Incident Response

Core Contribution — Forensic Auditor

Most AI security tools produce a report and stop. This one interrogates its own conclusions. After the Triage Agent finishes, a second Gemini instance — with access only to read-only ES|QL tools and no knowledge of the first agent's tool history — reissues fresh queries against Elasticsearch and labels every MITRE ATT&CK claim independently.

Results vary by investigation quality. When the Triage Agent gets every timestamp right, the Auditor returns all verified. When it hallucinates — a fabricated date, a wrong host, an inferred-but-absent technique — the Auditor catches it and cites the exact ES|QL output that contradicted the claim.

Run with clean triage output (May 2026):

Run with accurate triage output (June 2026):

Both outcomes are correct behaviour. Twenty refutals means the Triage Agent fabricated timestamps — the Auditor eliminated those false positives before the report was saved. Zero refutals means the Triage Agent got everything right and the Auditor confirmed it independently. Two examples from the run with refutals:

Reconstructed Attack Chain

15-step kill chain spanning two hosts and two and a half years (2019–2021), reconstructed from raw Windows event logs via ES|QL queries. Every step independently verified by the Forensic Auditor.

Architecture

The Triage Agent calls six ES|QL detection tools through the Elastic Agent Builder MCP server, routed via a Cloud Run proxy that handles auth injection and REST-to-JSON-RPC translation. Findings are written to an Elasticsearch memory index using ELSER sparse-vector + BM25 hybrid search. The Forensic Auditor runs as a second, isolated Gemini pass with read-only tool access.

Security Model

Security controls are architectural, not instructional. The model is never told to be careful — the code simply makes the bad path impossible.

• Session isolation search_memory is filtered by session_id at the Elasticsearch query level. The model cannot reach another investigation's data — it's not instructed away from it.
• Input validation time_window: regex match + 100-year DoS cap. host_name: alphanumeric allowlist + ES|QL char blocklist. All integers range-checked before any ES call.
• Write allowlist write_memory checks the target index against a hardcoded frozenset at write time. Setting ELASTIC_INDEX_MEMORY=ir-events in the environment is caught in the tool, not at config load.
• Content sanitisation Strips control characters and caps memory writes at 10,000 chars — blocking indirect prompt injection via poisoned retrieval results.
• Split API keys ELASTIC_API_KEY_READ for ES|QL queries. ELASTIC_API_KEY_WRITE for the memory index only. The read path cannot write under any circumstance.
• Chain-of-custody log Every tool call atomically appended via os.open/os.write — not buffered IO. Rejected calls log the rejection reason; allowed calls log duration and arguments.

Stack

• DataElastic Cloud Serverless — 73,909 Windows attack events, ECS schema, us-west1
• ToolsElastic Agent Builder — 6 ES|QL detection tools + memory, exposed via built-in MCP server
• MCP proxyCloud Run — REST → JSON-RPC 2.0 translation, auth injection, type coercion for Elastic MCP schema
• ReasoningGoogle Cloud Conversational Agents — Gemini 2.5 Flash, IR Investigation playbook
• MemoryElasticsearch hybrid search — ELSER sparse vectors + BM25 via RRF, session-scoped writes
• VerificationForensic Auditor — independent second Gemini pass, read-only tools, no shared context
• AuditChain-of-custody JSONL — atomic os.write per tool call, with duration and arguments
• DatasetEVTX-ATTACK-SAMPLES — 278 EVTX files, 2017–2023 real Windows attacks by Samir Bousseaden