AI
Why GenAI Endpoints Are a Blind Spot for Detection Engineers
Developers are installing AI coding tools faster than security teams can audit them. Cursor, Claude, and a growing list of MCP servers are already running on your endpoints. A Reddit post Ayenson flagged sums up the problem: a user noticed an extension making silent connections to livetickets.com and wrote, “I have no idea what extension it could be.”
Those tools spawn shells, write files, and make network calls, and your EDR has no clear visibility into what is driving any of it.
What Endpoint Telemetry Can and Cannot Tell You Today
DNS queries to Anthropic, ChatGPT, and Claude domains look normal. Code signatures on AI tool binaries are mostly valid and trusted. Process ancestry shows Claude and Cursor spawning git, gh, node, and bash — the same processes any developer runs. File writes touch .py files, config paths, and credentials. Every signal collapses into developer noise.
Elastic ships rules today for credential access via GenAI tools, unusual DNS, and suspicious URLs. Those rules fire. Then the real problem starts: you have a process ID, a user, a command line, and no way to answer the one question that matters. Did a human run that command or did the model?
“Good luck finding out if it is a human or an LLM did it” — Mika Ayenson
The Intent Attribution Gap: Human or AI?
The alert fires. A suspicious process ran.
“Good luck finding out if it is a human or an LLM did it” — Mika Ayenson
Same PID, same user, same command line. Current telemetry cannot distinguish a developer running curl from an AI agent that a poisoned repo file tricked into running it. The process tree shows cursor → cursor-helper → zsh → curl, but nothing in that chain records which prompt triggered the command or whether any human approved it. Defenders see the action. They never see the intent.
Detection Breaks Down: Process Ancestry, MCP Servers, and Cross-Session Loss
Matching on a single parent process name catches one level. It misses grandchildren, the full ancestry chain, and intent. Walking the full tree and correlating entity IDs across generations closes some of that gap.
MCP server detection is possible today. A command line running node under an MCP server pattern is recognizable. But which MCP tool ran? What trust level was granted? Those answers aren’t in the process tree. Cross-session abuse leaves no ancestry trace at all. Execution rules and credential-access alerts on sensitive file touches are a start, but the picture stays incomplete.
Agent Hooks, OpenTelemetry Semantics, and the Path to Full Observability
Today’s EDR sees process spawns, file events, and network calls. It does not see which prompt triggered them, which MCP tool ran, or whether the model refused a prior step. Agent hooks fix that: by intercepting pre-tool calls and session starts, they pull prompt context and tool call attribution into OpenTelemetry and push it to the SIEM.
“every production role is quite frankly a workaround for telemetry that should be built in natively” — Mika Ayenson
Elastic has already merged GenAI semantic fields into the OpenECS community schema. Claude Code emits those fields natively. Once other tools follow, one detection rule covers every tool that shares the same field names — no vendor-specific rewrites.
Practical Maturity Path: Start with Visibility, Build Toward Full Observability
Inventory first, rules second. Before writing a single detection, Ayenson recommends auditing which GenAI tools your org actually runs, restricting runtimes from executing as root, and deciding whether developers should stay browser-focused or go native. Network controls and DNS-level tagging come next. Elastic already ships open detection rules for credential access, persistence, and C2 activity via GenAI processes — those are a starting point, not a finish line.
“Start where you are, build towards full observability.” — Mika Ayenson
Layer hunting queries on top of that telemetry to build signal, then harden those into high-fidelity detection rules. The long-term target is native OpenTelemetry fields across every tool so one rule covers all of them.
Q&A
In an enterprise, how do you get your devs to actually do the agent hooks in the various tooling? If your EDR is mature enough to enforce policy, roll out hooks through it directly — otherwise share hook scripts via an internal skills repo, but enforcement requires the endpoint route. ▶ 19:16
If I already have observability into network activity, process activity, endpoint telemetry, do I really care if it was an agent or a human? Yes, because knowing whether a developer made a deliberate bad decision or blindly clicked through an AI suggestion changes the risk assessment and the response. ▶ 21:36
Notable Quotes
Good luck finding out if it is a human or an LLM did it Mika Ayenson · ▶ 6:00
every production role is quite frankly a workaround for telemetry that should be built in natively Mika Ayenson · ▶ 13:46
Start where you are, build towards full observability. Mika Ayenson · ▶ 18:02
Key Takeaways
- Audit your GenAI tool inventory and restrict runtimes before writing a single detection rule.
- Walk the full process ancestry tree — parent process name alone misses multi-level AI agent chains.
- Push your AI tooling vendors to emit OpenTelemetry-compatible fields so detection rules work across every tool.