Endpoint telemetry for AI: what SOCs need to capture

Endpoint telemetry for AI is a local-first record of the intent-to-action chain, the path from a prompt, through the tool calls it triggers, to the actual effects on the endpoint. It exists because traditional EDR and network telemetry catch the effects of agent activity (a spawned process, an outbound connection) without ever recording the prompt or tool decision that caused them. A working deployment gives your SOC three things it didn't have before:

• A readable audit trail linking a prompt to every downstream action it caused
• Faster triage, because analysts stop guessing why a process appeared
• Better data-loss prevention coverage for AI workflows that never touch a traditional DLP chokepoint

None of this replaces EDR. It sits alongside it, filling in the context EDR was never built to see.

Key Takeaways

Endpoint telemetry for AI works because it records the intent-to-action chain, prompt, tool call, endpoint effect, that EDR and network tools were never built to see.

Table of Contents

• What endpoint telemetry for AI actually includes
• The visibility gap: what EDR and network tools miss
• Signals and telemetry to prioritise: an operational checklist
• Implementation best practices and architecture patterns
• Detection engineering: tuning rules for AI agent behaviour
• Operationalising telemetry: SIEM, SOAR and incident response
• How AIDR maps to the endpoint telemetry checklist
• What most agent-security advice gets backwards
• See how Alectura closes the endpoint AI visibility gap
• Sources

What endpoint telemetry for AI actually includes

Agent-aware telemetry means capturing specific event types, not just "more logs." The core set security teams should collect looks like this:

• Prompt and session captures (what was asked, when, by whom, in which session)
• Tool and MCP invocations (which server, which function, what parameters)
• Pre and post-tool spans (state before and after a tool runs)
• Shell execution records, including the parent process that launched them
• File reads, writes, and diffs
• Process trees showing lineage from agent to child process
• Credential access attempts
• Outbound network destinations tied to a specific agent action

Schema matters as much as coverage. The OpenTelemetry GenAI semantic conventions define how agent events map to spans and logs, and pairing that with JSONL or OTLP output means the data is queryable in whatever backend your SOC already runs. Session IDs and trace IDs are what let you correlate a prompt with the shell command it triggered three steps later.

Consider this the forensic chain you're actually after: a user prompts an assistant to "clean up the temp folder," the agent decides to invoke a shell tool, that shell process spawns rm -rf, and a file-write event confirms the deletion. Without telemetry linking those four records by session ID, an analyst sees an unexplained deletion. With it, they see the full decision path in seconds.

The visibility gap: what EDR and network tools miss

EDR was built to see processes, file changes, and network connections. It was not built to see why those things happened when the "why" originates inside an AI agent's reasoning loop rather than a human clicking a button. That gap creates specific blind spots:

1. Local MCP calls never touch the network stack, so a network monitor sees nothing when an agent queries a local MCP server for file access or credentials.
2. Agent session metadata is invisible to EDR — the tool sees the resulting process, not the session, the model, or the prompt that spawned it.
3. Subagent orchestration compounds the problem. When one agent spins up subagents to parallelise a task, EDR sees a burst of related processes with no shared parent context tying them together.
4. Approval steps leave no trace. If a human approved a risky action inside an agent's own UI, that approval lives nowhere EDR can query it.

The operational cost is real. Analysts spend longer on triage because an alert reads as ambiguous, a process spawned a shell, wrote to a sensitive directory, and made an outbound call, with no way to tell whether it was sanctioned automation or something worse. Enterprise benchmarks in 2026 found that AI coding agents routinely trigger EDR behavioural rules because their execution patterns, rapid file writes, credential lookups, process chaining, closely resemble adversary tradecraft. Without the missing context, that resemblance becomes an incident that eats analyst hours for nothing, or worse, a genuine policy violation that gets waved through as "probably the AI tool again."

Signals and telemetry to prioritise: an operational checklist

Not every signal deserves the same engineering effort on day one. Build in this order:

1. Discovery and inventory — know which AI tools, copilots, and MCP servers actually run on your fleet before you try to instrument them.
2. Session and prompt capture — establish the session ID as your correlation anchor before anything else.
3. Tool and MCP call logging — record what was invoked, with what parameters, and what it returned.
4. Shell execution traces — tie every spawned process back to the session that caused it.
5. File I/O diffs — capture before/after state, not just "a write occurred."
6. Credential access attempts — flag any agent reaching for stored secrets or tokens.
7. Outbound destinations — log where data goes, correlated to the session that sent it.

Privacy and redaction need to be designed in from the start, not bolted on later. Prompt content frequently contains PII, source code, or business-sensitive detail, so redact known-sensitive patterns (API keys, credit card numbers, personal identifiers) at the collection point, before the record ever leaves the endpoint. Normalise everything against a common identifier set: session ID, trace ID, host identifier, and user identifier, so a query across tools returns one coherent timeline instead of four disconnected logs.

Pro Tip: Don't redact so aggressively that you destroy investigative value. Hash or truncate sensitive fields rather than dropping them entirely; a hashed match is still useful for correlating "the same secret appeared in three sessions" even when you can't read the value.

Implementation best practices and architecture patterns

Local-first collection is the architectural decision that matters most, and it's worth explaining why. Prompts and tool calls often contain the most sensitive context in the entire pipeline, and shipping raw prompt content off-device by default multiplies your data-exposure surface. A local-first collector captures the full record on the endpoint, applies redaction there, and only forwards what your policy allows.

Practical architecture patterns that work:

• Run a lightweight collector as an agent or MDM-deployed component, not a separate heavyweight install that fights with your existing EDR for resource priority.
• Export via OTLP into whatever observability backend you already run, rather than building a bespoke pipeline. Open-source projects like Agent Beacon demonstrate this pattern directly, normalising agent events into JSONL and OTLP so they slot into existing SIEM ingestion without custom parsers.
• Keep a stable local JSONL store as your forensic fallback, even if you forward everything else. If the network link is down or the SIEM ingestion queue backs up, you still have the raw record on-device.
• Set retention windows that match your compliance obligations, not your storage budget. Thirty days of full-fidelity prompt data might satisfy an internal audit; a regulatory request might need longer.
• Apply role-based access to telemetry itself. A prompt log containing source code or customer data is sensitive data in its own right, and it needs the same access controls you'd put on the systems it describes.
• For CI/CD environments, deploy the same collector pattern as a runner-level component, so agent activity inside build pipelines gets the same visibility as activity on a laptop.

Project Telescope takes this further with an MCP proxy and collector SDK that captures agent sessions and side effects without sending telemetry off-device by default, a useful reference if you're weighing build-versus-adopt decisions. Compatibility with your existing EDR agent matters too: test for resource contention and event duplication before a fleet-wide rollout, not after.

Detection engineering: tuning rules for AI agent behaviour

Agents trip credential-access and execution rules constantly, not because they're compromised, but because a legitimate coding assistant reading environment variables looks structurally identical to credential harvesting. Sophos's analysis of agent behavioural telemetry found agents performing multi-step sequences, chained execution, alternate download paths, process pivoting, that read as attacker tradecraft on a single-signal detection.

The fix is correlation, not suppression:

• Tie credential-access alerts to the session and prompt context that preceded them; a benign "read this config file" prompt looks nothing like a harvesting attempt once you can see the request that caused it.
• Weight file-diff content and destination reputation alongside the raw execution event, rather than alerting on execution alone.
• Expect agents to pivot when one path is blocked. Detection engineers should build rules that account for adaptive behaviour, an agent trying an alternate LOLBin after the first attempt fails is not automatically more suspicious than the first attempt; it might just be persistent automation.

Pro Tip: Roll every new agent-aware rule through a greylist stage first. Log matches without alerting for a week, then check the false-positive rate against your analyst feedback before promoting it to a firing rule.

Operationalising telemetry: SIEM, SOAR and incident response

Getting agent telemetry into your SIEM means mapping it to fields your analysts already query: session ID as correlation key, tool/MCP call as an event type alongside process and network events, and prompt metadata as enrichment rather than a standalone alert source. Build dashboards that show the full session timeline, not just the flagged event, so an analyst sees the three steps before and after in one view.

For SOAR playbooks, agent-driven incidents call for a specific pattern:

• Enrichment first — pull the session's full prompt-to-effect chain before any containment decision.
• Containment triggers scoped to confidence level — auto-isolate on high-confidence indicators (known-bad destination, confirmed secret exfiltration); route ambiguous cases to analyst-assisted approval.
• Retention tuned to your regulatory exposure — a data-loss investigation or a subpoena response needs the full session record, not a summary.

How AIDR maps to the endpoint telemetry checklist

Everything above describes a capability gap. Alectura's AI Detection & Response platform is one way to close it, and mapping its features against the checklist shows where the overlap sits:

• Discovery and inventory of AI tools, copilots, and MCP servers across the fleet, covering priority one from the checklist
• A prompt timeline that captures session context, directly addressing the session/prompt-capture layer
• MCP monitoring that surfaces local tool calls invisible to network-based tools
• Built-in DLP and redaction controls applied at the point of collection, not after the fact
• Centralised policy enforcement that turns telemetry into guardrails rather than just logs

Whichever platform you evaluate, hold it to the same standard: ask for its telemetry schema, ask what redaction controls exist and where they apply, and ask whether artefacts are open enough to inspect. A vendor that can't answer those three questions plainly isn't ready for a SOC that needs to trust its own audit trail.

What most agent-security advice gets backwards

Most guidance on securing AI agents starts with policy, acceptable-use documents, model allow-lists, prompt guidelines, before it touches telemetry. That order is backwards. A policy nobody can verify is a wish, not a control. The judgement this research actually supports is that visibility has to come first, because you cannot enforce a rule about agent behaviour you cannot observe in the first place.

The conventional wisdom also treats agent-triggered EDR alerts as a tuning problem to suppress. It's not. The pattern where coding agents trip behavioural rules is a symptom that your EDR is doing exactly its job, seeing execution patterns that genuinely resemble compromise, without the one piece of context that would resolve the ambiguity: the prompt. Suppressing those alerts blindly is how a real intrusion slips past disguised as "just the AI tool again."

If you take one thing from this guide, prioritise the session-and-prompt-capture layer before anything else. Everything downstream, detection tuning, SOAR playbooks, audit trails, depends on that correlation anchor existing first.

— Nathan

See how Alectura closes the endpoint AI visibility gap

Every pattern in this guide, local-first collection, session correlation, redaction at the point of capture, is what Alectura's AI Detection & Response platform runs as a deployed product rather than a build-it-yourself project. It discovers the AI tools already running across your fleet, builds a prompt timeline for every session, watches what agents touch through MCP, and flags secrets or policy violations before they leave the device.

For a security team weighing whether to build this stack internally or adopt it, the practical difference is time to coverage: AIDR ships the discovery, inventory, and DLP layers this guide describes as separate engineering projects, already wired together. Read what AIDR actually does and check how it handles a specific high-risk tool, including the guardrails covering DeepSeek, then request a walkthrough against your own fleet's AI footprint.

Sources

Consult the NIST Cybersecurity Framework and the CISA EDR implementation toolkit for governance baselines. This guidance is globally applicable; check local policy for jurisdictional requirements before deployment.

• Local-first observability for AI agents (Microsoft)
• When AI agents look like attackers: what behavioural telemetry tells us (Sophos)
• AI coding agents found triggering EDR rules (The Hacker News)

Recommended

• AI agent monitoring for enterprise SOC teams
• Best LLM monitoring tools for enterprise SOCs
• AI observability tools for enterprise security teams
• AI data exfiltration: what to detect and how to stop it