Endpoint Telemetry Indicators for Shadow Agent Processes

Shadow agent processes leave detectable traces in process trees, network traffic, file writes, and credential use. To find employees using unauthorized MCP servers, security teams need to correlate those traces with an approved deployment inventory and the identity behind each tool call. Detection closes the gap only when tool-level policies can stop unauthorized actions before they execute.

Why shadow agents are structurally invisible to conventional endpoint tools

Conventional endpoint tools can see an agent’s activity without recognizing what it means. MCP gives agents a standard interface to databases, APIs, code repositories, email, and internal tools. That shared interface also creates a scalable attack surface, because an agent can use an employee’s credentials across those systems without a second approval after the initial prompt. EDR and DLP can record outcomes, but they were not designed to evaluate the intent or causal chain behind each tool call.

That distinction matters when an agent reads a sensitive document, paraphrases it, and sends the result over ordinary HTTPS to an AI vendor API. A DLP pattern match can miss the transfer entirely. Runlayer fills part of this gap by tying identity to MCP actions through SSO and enforcing policies for each tool call, so teams have more than endpoint alerts to work with. Endpoint telemetry still provides the upstream evidence, including the process that ran, the connection it opened, the files it touched, and the credentials it used. Endpoint telemetry still does not establish how those events relate to an authorized task.

How do unauthorized MCP servers land on employee endpoints?

A shadow deployment starts when an employee sets up an agent or MCP integration outside procurement and security review. The setup still leaves artifacts, even when it has no record in the inventory. Configuration writes on an endpoint with no approved agent deployment are therefore useful evidence of entry.

MCP uses a client-server model in which the AI agent is the client. On an endpoint, the resulting process chain typically starts under the developer’s IDE, terminal, or browser. Local deployment is important here, because roughly four in five of the most-searched MCP servers are local. A remote MCP connection instead produces outbound traffic from a user-space process to an external endpoint that may be new to the environment. Both paths can bypass the systems security teams normally use to approve software and access to services.

Qualys’s MCP shadow-IT analysis identifies the underlying inventory problem. Most security teams have not mapped which MCP servers exist or what each exposes. Without that map, a process or connection cannot be judged against an approved deployment. The deployment path supplies the first clues, but the activity that follows supplies the stronger evidence.

Process tree and spawn-chain indicators that distinguish agent activity from normal application behavior

Process telemetry becomes useful when it preserves ancestry. An MCP client may appear under Cursor, VS Code, Windsurf, Zed, or a terminal emulator, then spawn further children for tool invocations. The depth, branching, and rapid sequence of those children can differ from ordinary developer activity. By contrast, a process named node, python, or npx can look legitimate on its own. Its name and hash do not explain why it ran or what caused the next process to start.

Persistence adds another signal to that chain. An agent that survives a reboot or relaunches without user interaction has established persistence. New Run keys, launchd plists, or systemd units are therefore relevant indicators when they connect a startup entry to MCP server binaries or agent runners.

Sophos found that legitimate agents also generate alerts that can desensitize teams to real threats. Knowing which agents are approved, with help from governance platforms such as Runlayer, lets teams tune those rules without treating every agent as an intruder. Uber’s ADR system adds causal context by capturing the prompt, reasoning chain, tool calls, and outcome of coding-agent sessions. Presented at MLSys 2026 and open-sourced, it correlates LLM reasoning logs with MCP telemetry to identify misuse that executable names alone cannot establish.

Network behavior patterns that expose an agent's tool calls and exfiltration attempts

MCP’s SSE transport, or Server-Sent Events, opens HTTP connections to external hosts and keeps them open. That durable connection differs from the burst-and-close pattern of ordinary API calls and deserves attention when it comes from a user-space process. DNS logs add another clue when an IDE or terminal child resolves a previously unseen domain for a public MCP registry or remote server. Neither clue requires full payload inspection.

In the Supabase MCP incident, a prompt-injected agent queried an integration_tokens table and posted live tokens to a public thread over ordinary HTTPS. No DLP rule fired because the traffic matched no known pattern and went to a trusted SaaS host. Invariant Labs reported a related GitHub incident in which an agent with elevated access followed instructions in external content and leaked data through a pull request in a public repository. The network operation resembled legitimate tool use even though its purpose was not legitimate.

Baseline outbound call volume and destination diversity for agent-associated processes. A sudden spread of first-seen hosts or frequent calls to a small set of AI vendor APIs gives teams reason to investigate. Inbound traffic matters too, as the Azure MCP Server authentication bypass illustrates. CVE-2026-32211, rated CVSS 9.1 and dated April 3, 2026, allowed an attacker reaching an unauthenticated endpoint to enumerate API keys and authentication tokens. Unexpected source IPs or CIDR ranges connecting to MCP server ports are the relevant network indicator.

File system patterns left by agent configuration, credential storage, and tool-generated writes

Known targets include.claude/settings.json, ~/.openclaw/credentials/, and ~/.clawdbot/.env, with equivalent paths on Windows and macOS. Creates or writes at these locations are high-fidelity indicators when the endpoint has no approved agent deployment record. That condition matters because an authorized installation can touch the same paths. A unified inventory, including the shadow-AI discovery offered by Runlayer’s AI control plane, provides the context needed to distinguish legitimate deployments from shadow instances.

Credential files expose a second part of the footprint. Developers store API keys in environment variable files and hardcode OAuth tokens in configuration files because long-lived secrets are easier to work with than short-lived scoped tokens. Writes or modifications by a non-installer process can therefore indicate shadow credential management. Without centralized credential management, separate MCP server configurations spread secrets across projects. An exposed secret can then provide access to downstream systems connected through that server.

A coding agent attempting to write into /etc/, a home directory’s SSH folder, or a system binary path is a critical indicator even if the write fails. The Claude Code RCE incidents reported in January–February 2026 exploited poisoned repository configuration files, and reports of the underlying issues began in mid-2025. Monitoring writes to.claude/ paths by non-user processes would have surfaced the relevant configuration changes. Add these agent paths to file-integrity monitoring and treat unexpected modifications with the severity of changes to SSH authorized_keys.

Credential usage anomalies that reveal an agent operating outside its intended scope

A credential may usually make a few calls per hour during working hours from a known IP range. If it suddenly makes machine-paced calls across many resources at off-hours, with activity tied to an endpoint process rather than a browser session, the pattern has changed. The useful comparison is with that employee’s normal behavior. Automation alone is not proof of misuse, but a sharp departure supplies evidence for investigation.

Resource choice can be more revealing than speed. A shadow agent inherits the deploying employee’s permissions, which may cover more than the employee routinely uses. Access to adjacent databases, repositories in other teams’ namespaces, or internal APIs outside the employee’s workflow is a lateral movement indicator. The credential can be valid even when the action falls outside the task the agent was meant to do.

On-Behalf-Of authentication, or OBO, makes that distinction easier to enforce and observe. Each agent request exercises a delegated subset of the initiating human’s permissions, scoped to the downstream service and bounded by that person’s existing access. The telemetry benefit is direct attribution to a specific user. That identity gives the other layers a common reference, so a file write, process launch, and remote call can be evaluated as parts of the same action.

Why correlating signals across all four telemetry layers is what closes the detection gap

An IDE spawning node can be ordinary development, and a long-lived SSE connection can be approved MCP use. Machine-paced credential activity can also be expected automation. When those events follow a write to a known agent configuration path on an endpoint without an approved deployment, the combined picture is much stronger.

Uber’s ADR shows how this approach works at enterprise scale. It processes tens of thousands of agent sessions a day across thousands of endpoints using a two-tier detector. A fast first pass built for high recall clears ordinary sessions, while sessions that pass through triage get a closer look using source code, threat intelligence, and the policies that apply. In threat emulation tests, ADR detected prompt manipulation and subsequent remote code execution attempts by correlating LLM reasoning logs with MCP telemetry.

Discovery and tracing provide different parts of that context. Qualys TotalAI uses graph-based relationship mapping to link the MCP servers it finds to what they expose, so the inventory becomes an attack surface map. Agent identity and records of approved deployments help teams tell when credential access, downloads through legitimate system tools, and persistence come from legitimate agents or intruders. Full OpenTelemetry traces connect a tool call to the originating prompt, agent identity, credential, and endpoint process. Without that chain, teams must reconstruct events manually across logs, and false positives can recreate the blindness detection was meant to remove.

What governance and authentication controls make telemetry operationally useful rather than a forensic afterthought

Correlation explains an action, but governance sets the rules for whether it should run. MCP’s original specification lacked a mandatory authentication framework. The November 2025 specification introduced incremental scope consent, and the July 2026 update clarified scope accumulation during step-up authorization. Enterprise-Managed Authorization was declared stable in June 2026. These controls still need an authorization layer that understands individual tools, which most deployments do not yet have.

Identity must remain intact from the end user through the AI host, MCP client, MCP server, and downstream API. Shared service accounts or cached credentials can break that chain and leave logs unable to identify the human who authorized an action. The same break allows a server to act with broader privileges than the user should have. AGAT Software distinguishes reactive log review from a gateway that intercepts tool invocations before execution, scores risk, and sends high-risk actions for human approval.

Runlayer is one option for combining those controls with the evidence needed for detection. Its control layer ties identity to MCP actions through SSO, SCIM, and OBO/M2M tokens. Its security layer detects MCP-specific threats, including tool poisoning, prompt injection, output manipulation, and exfiltration, while tamper-proof audit logs and full OTEL tracing preserve the action chain. These capabilities address a different need from endpoint detection or server discovery, because they make identity and policy available at execution time.

The operational goal is not to force every useful integration underground. An approved agent option, sandboxed tool execution, narrow permissions for each agent, and logs give employees a way to use agents under those controls. Security then becomes a way to enable that use while keeping actions attributable and enforceable. That is how enterprises stop chasing isolated shadow deployments and start controlling the access that makes them consequential.