Speaker:: Mika Ayenson Title:: "Can You See What Your AI Saw?" Duration:: 22 min Video:: https://www.youtube.com/watch?v=cEbPSQaSLXM ## Key Thesis Traditional endpoint telemetry — process spawns, file writes, network calls — is fundamentally insufficient for detecting malicious or anomalous AI agent behavior because intent attribution is broken: human-initiated and AI-initiated actions produce nearly identical artifacts. The industry needs a new observability layer built around agent hooks, standardized telemetry semantics (OpenTelemetry), and richer per-tool-call context to differentiate human from agent decisions. ## Synopsis Mika Ayenson, team lead for threat research and detection engineering at Elastic, laid out the detection engineering problem created by the explosion of AI coding tools (Claude Code, Cursor, Copilot, etc.) running on developer endpoints. The talk is grounded in real Elastic telemetry rather than theoretical threat modeling. The core problem Ayenson documented is **intent attribution failure**. From the EDR's perspective, a developer running a shell command and Claude Code autonomously running the same shell command produce identical process trees — same PID, same user, same command line. There is no native signal indicating whether a human or an AI decided to execute a given action. This makes standard detection rules effectively useless for the new threat class. He walked through the available telemetry categories and their limitations: - **DNS/network**: useful for flagging unexpected destinations, but AI tools legitimately call Anthropic, OpenAI, etc., creating huge noise floors - **Code signatures**: most AI tools are signed and trusted; unsigned binary rules yield weak signal - **Process ancestry**: you can see `cursor → cursor-helper → zsh → curl`, but you lose the prompt that triggered it and can't attribute across the full ancestry tree - **File modifications**: AI tools touching config files, credential stores, or plist files can be flagged, but the same touch events are routine for legitimate development - **Long chained command lines**: AI tools generate multi-piped commands that are difficult for analysts to parse, and legitimate development looks similar The deeper threat model Ayenson outlined involves **prompt injection via poisoned repo files** — an adversary embeds malicious instructions in a file that an AI agent reads, which then triggers exfiltration or persistence via what appears to be normal developer activity. The EDR sees `cursor-helper → zsh → curl [exfil URL]` with no visible link to the poisoned source file. His proposed path forward centers on two things. First, **agent hooks**: pre-tool-call and session-start hooks that can capture prompt context and tool invocation metadata, pushing that data into OpenTelemetry and then into SIEM/EDR. Claude Code already emits some OpenTelemetry-compatible fields natively; other tools are behind. Second, **standardized AI semantics in OpenTelemetry**: Elastic has worked with the OpenTelemetry community to establish baseline `genai.*` fields so detection rules can be written once across tools rather than per-vendor. With full hook-based observability, analysts could know: which prompt triggered an action, which MCP tool was called, whether the action was user-approved or agent-initiated, and what the model's provider was. Ayenson closed with a maturity model: start with what you have today (DNS-first, process ancestry heuristics, credential access monitoring), layer in guardrails and network controls, and build toward full observability with native agent hooks. Elastic's detection rules for AI agent behavior are open source on GitHub. ## Key Takeaways - Human-initiated and AI-initiated actions produce near-identical EDR telemetry — intent attribution is fundamentally broken with today's tooling - Process parent name alone is insufficient; full ancestry tree walking is needed to identify AI tool lineage, but still misses the causative prompt - Prompt injection via poisoned repo files is a real attack class where the EDR sees only benign-looking processes - Agent hooks (pre-tool-call intercepts) feeding OpenTelemetry are the right architectural fix — Claude Code already partially supports this - Standardized `genai.*` semantic fields in OpenTelemetry are essential so detection rules don't have to be rewritten per tool vendor - Every production detection rule today is "a workaround for telemetry that should be built in natively" - Reduce attack surface before writing rules: audit which AI tools your org uses, whether they need to run as root, and whether network controls are appropriate - Separating browser-based from native AI tool access simplifies detection scope significantly ## Notable Quotes / Data Points - "Every production rule is quite frankly a workaround for telemetry that should be built in natively" - Elastic telemetry showed very few unsigned code-signature binaries from AI tools — most are signed and trusted, making simple unsigned-process rules weak - "The alert fired, a suspicious process ran. Good luck finding out if it is a human or an LLM did it" - Claude Code is called out as "the exception" — it already emits OpenTelemetry-compatible fields natively, ahead of most competitors - Cross-session context stitching is an open detection problem: an adversary could split a multi-stage attack across multiple agent sessions to evade session-scoped detection - Ayenson's detection rules available at two Elastic GitHub repos (referenced in talk slides) #unprompted #claude