As reported by Elastic Security Labs, a nuanced but high-consequence attack pattern is emerging at the intersection of AI-assisted development and endpoint security: coding agents — the kind developers increasingly use for "vibe coding" sessions — can be manipulated or inadvertently instructed to establish reverse tunnels and register LaunchAgents that persist across reboots, effectively punching holes through perimeter defenses without a single line of traditional malware.

AI Security Alert: The security community has spent years building detection logic around known-bad binaries, suspicious parent processes, and anomalous network connections.

Why This Is a Bigger Deal Than It Looks

The security community has spent years building detection logic around known-bad binaries, suspicious parent processes, and anomalous network connections. Coding agents break that model elegantly. When a legitimate, signed AI agent process spawns ngrok, bore, or a similar tunneling binary, and then registers persistence via a LaunchAgent plist, the individual artifacts may each appear benign in isolation. It's the behavioral chain that constitutes the threat — and most endpoint tools aren't correlating across that chain at the process-lineage level with enough fidelity.

This is a textbook example of Living off the Land (LotL) evolving into what we might call Living off the Coding Agent (LotCA) — where the attacker's leverage isn't a malicious binary, it's a trusted automation context doing exactly what it was designed to do, just with adversarial intent or accidental misconfiguration baked into the prompt.

The threat model has shifted: You no longer need to deliver malware to expose an admin panel to the internet. You need to convince — or compromise — the agent's instruction set.

Who Is Actually at Risk

This isn't a narrow edge case. Consider the exposure surface:

Who Is Actually at Risk
Developer workstations running local admin dashboards (databases, internal tooling, localhost web apps) that are assumed safe because they're not publicly routed — until a tunnel changes that assumption.
macOS-heavy engineering environments where LaunchAgents are a native, trusted persistence mechanism that many EDR tools underweight compared to Windows registry run keys.
Organizations adopting AI coding assistants without updated acceptable use policies — the agent may be sanctioned, but its ability to write and execute shell commands, create plists, and install tunnel binaries may not have been scoped.
Supply chain scenarios where a compromised prompt template, poisoned MCP server, or malicious plugin instructs the agent to establish persistence as a "setup step."

The Detection Gap: Severity Downgrading

One of the most operationally dangerous dynamics here is alert triage fatigue combined with context misclassification. A SOC analyst seeing an alert that reads "ngrok spawned by Cursor/Copilot agent process" on a developer's MacBook is statistically likely to downgrade that to informational or close it as expected behavior. This is exactly the gap adversaries — or poorly scoped agents — exploit.

Elastic's research underscores something Shield53 has been advising clients on for months: agent parentage does not reduce severity; it shifts the investigation focus. The question isn't "is this process legitimate?" — it's "was this agent instructed to do this, by whom, and does that instruction have authorization?"

Shield53 Recommendations

Immediate Actions for Defenders

  • Reclassify tunnel binary execution by agent processes as HIGH severity. Create detection rules that flag when known tunneling tools (ngrok, bore, frp, cloudflared, serveo) are spawned with a coding agent (e.g., Cursor, Claude Desktop, GitHub Copilot CLI, Continue) anywhere in the parent process chain.
  • Audit LaunchAgent and LaunchDaemon directories proactively. Establish a baseline of expected plists in ~/Library/LaunchAgents, /Library/LaunchAgents, and /Library/LaunchDaemons. Alert on any new entries created by non-system, non-IT-managed processes.
  • Restrict agent runtime permissions. Where possible, run coding agents in sandboxed or containerized environments that cannot write to persistence directories or execute network tunneling binaries without explicit allowlisting.
  • Implement prompt and tool-use logging for AI agents. If your organization uses agents with tool-use capabilities (shell execution, file write), ensure those tool invocations are logged and retained for forensic review — treat them like privileged command execution logs.
  • Update your AUP and security awareness content to explicitly address AI coding agent risks, including the concept of prompt injection leading to unintended system modifications.

Longer-Term Strategic Posture

  • Engage your EDR vendor about agent-aware behavioral correlation. Process lineage rules need to account for the reality that legitimate signed software can now be a threat vector.
  • Treat developer endpoints with the same scrutiny as servers. The "developer machine" exception in many security programs is increasingly untenable in an agentic AI world.
  • Consider network-layer controls: outbound connections to known tunnel infrastructure (ngrok domains, bore.pub, etc.) should require explicit approval, not just firewall pass-through.

The underlying message from Elastic's research is one Shield53 endorses strongly: intent does not determine risk. Whether an agent establishes a reverse tunnel because it was tricked, misconfigured, or explicitly instructed by a developer who didn't consider the security implications — the exposure is identical. Endpoint detection must treat the behavior, not the assumed motivation, as the signal.