Skip to content

Back to the catalog

Critical Security Controls for Governing AI Coding Agents | Blog | Endor Labs
endorlabs.comarticle

Critical Security Controls for Governing AI Coding Agents | Blog | Endor Labs

Endor Labs analyzes the security risks of AI coding agents running on developer laptops with shell, filesystem, network access and the developer's own credentials, framing the threat as prompt-injection-driven abuse of legitimate agent capabilities (e.g., an agent tricked into exfiltrating .env via a malicious README). It maps six control points — EDR/XDR, sandboxes/containers, AI/MCP gateways, in-agent hooks, package firewalls, and secrets scanning/PR controls — arguing that in-agent hooks (deterministic allow/deny/ask decisions on proposed actions before execution) are the only point that intercepts model intent before it becomes a shell command, and promotes Endor Labs' own hook-based AI Coding Agent Governance and Package Firewall products as the implementation.

TL;DR Endor Labs proposes a six-layer defense-in-depth model for AI coding agents, arguing in-agent hooks are the key control point since EDR, sandboxes, and MCP/AI gateways can't see or judge agent intent before action.
Document

What it is

An Endor Labs blog post mapping the six enforcement points for AI coding agents and naming which shipping tools occupy each. The summary already covers the six points and the hooks thesis; the value here is the concrete tooling and the specific positional limits of each control.

How it works

Each control sees a different slice of the agent loop, and the page pins down what each can and cannot see:

  • EDR/XDR — watches the OS; sees processes, files, sockets. Microsoft Defender's local agent discovery now recognizes 35+ agent types. Limit: it sees curl running, not the reasoning that produced it, and only after the process exists.
  • Sandboxes/containers — the strongest boundary. Claude Code has a Seatbelt/bubblewrap sandbox scoped to Bash; Codex CLI sandboxes by default; GitHub Copilot CLI added local sandboxing in public preview on 2 June; Docker Sandboxes and Apple's Containerization framework isolate at VM-per-container. Limit: inside the boundary, a dangerous command runs normally.
  • AI/MCP gateways — sit on the network path to the model; control model access, inspect prompts, cap spend. Limit: blind to local shell, local file reads, and local stdio MCP servers.
  • In-agent hooks — the only point between model intent and action; where Endor's AI Coding Agent Governance operates.
  • Package firewalls — Endor Labs Package Firewall evaluates every package including transitives; malware blocks by default, while vulnerabilities, licenses, and minimum package age are warn/block policies.
  • Secrets scanning / PR controls — the backstop, but runs after the fact.

Why hooks

The hook receives the proposed shell command as a string before the shell runs it and returns allow/deny/ask. A regex isn't subject to jailbreaks — if policy blocks rm -rf /, it blocks it regardless of the reasoning trace. Denials also carry a machine-readable reason so the agent corrects course rather than retrying the same wall. (The page's list of "four things" is cut off after the second.)

What to do

Nothing to patch. The actionable takeaway is architectural: no single control covers the loop, so combine sandboxing (the strongest boundary) with in-agent hooks (the only intent-stage gate) rather than relying on EDR or MCP gateways, which are positionally blind to the relevant actions.

Caveats

Vendor content — the hooks and package-firewall arguments map to Endor's own products. The claim that EDR/MCP gateways are "inadequate" is the author's framing; the post concedes those controls remain "arguably necessary." The 2 June sandbox date is given without a year. The hooks section is truncated mid-list in the fetched text.

Technologies named here

Techniques named here