Introduction
Let’s start with an obvious statement: developers are using AI coding assistants to create the code for the applications and features they design. So what? Well, these agents read more files, touch more of the filesystem, and produce larger commits than the developer would alone, and all of it runs on a laptop with that developer's credentials loaded.
The agentic development stack assembled itself on those laptops over about eighteen months, without a procurement cycle, a threat model, or a control plan. This has, somewhat predictably, created an attack surface that adversaries have leveraged to steal credentials and secrets, which are then used to spread malicious code, which then repeats the cycle.
The appeal of a developer’s workstation is easy to understand: a combination of powerful desktop agents, a pattern of performing software installs, and a credential-rich environment make this a prime target for bad actors.
The good news is that protecting endpoints is a mature cybersecurity practice. The bad news is that most of these controls are inadequate to defend against these specific attack types (although still arguably necessary). In addition, some new tools like Model Context Protocol (MCP) gateways, while not without value, are less useful in protecting workstations than you might think.
What we are actually defending against
An AI coding agent is a process on a developer's machine with a shell, filesystem access, network access, and the developer's credentials. It reads your repository and runs commands. That is the job, and the risk follows from the capability. An agent that can run npm install
can also read .env
and POST it somewhere. An agent that can edit Terraform can run terraform destroy
. Because the interface is natural language, anyone who can plant a sentence where the agent will read it, in a README, an issue comment, or a package description, can try to talk it into doing something it should not. The action then runs at machine speed with the developer's own permissions, so it looks legitimate on the way past.
In addition, AI coding agents can and will install third-party libraries in order to test the software they create, exposing workstations to the risk of malware embedded in package install scripts.
This is where a vendor likes to position a ‘buy this, and it solves everything’ product, but any seasoned security professional knows that’s bunk. Good protection requires defense in depth, which rarely comes from one tool alone (although your friendly vendors are always working hard to get there).
Six places to enforce control
There are six places we can enforce controls on AI coding agents:
- EDR and XDR
- Sandboxes and containers
- AI gateway and MCP gateways
- In-agent hooks
- Package firewalls
- Secrets scanning and pull request controls
Each of these sees a genuinely different slice of the agent loop.
EDR and XDR watch the operating system. When the agent spawns a process, touches a file, or opens a socket, the sensor sees it. This is mature technology with real detection engineering behind it, and the three largest vendors all shipped AI agent discovery in the last year. Defender's local agent discovery now recognizes more than 35 agent types, a useful signal about how many of these are in circulation. The limitation is positional rather than qualitative. The sensor sees curl
running. It does not see the reasoning that produced curl, and by the time it has an opinion, the process exists.
Sandboxes and containers constrain what an action can reach. Claude Code has a Seatbelt and bubblewrap sandbox scoped to Bash, Codex CLI sandboxes by default, GitHub Copilot CLI added local sandboxing in public preview on 2 June, and Docker Sandboxes and Apple's Containerization framework push isolation up to a virtual machine per container. Sandboxes are the strongest boundary available, and we recommend them. They have no opinion about intent, though: inside the boundary, a dangerous command runs normally.
AI gateways and MCP gateways sit on the network path to the model. They control which models developers reach, inspect prompts, and cap spend. They cannot see local shell execution, local file reads, or local stdio MCP servers, because none of that traffic passes through them.
In-agent hooks intercept the agent's own lifecycle. The harness hands your code a structured description of the action it is about to take and reads back a decision. This is the only control point sitting between the model's intent and the action, and it is where Endor Labs Agent Governance operates.
Package firewalls sit between the package manager and the public registry. Endor Labs Package Firewall evaluates every package in the dependency tree, transitives included. The malware check blocks by default. Vulnerabilities, restricted licenses, and minimum package age are policy-driven, and each can be set to warn or block.
Secrets scanning and pull request controls are the backstop. They work well, but they also run after the fact, which is often too late.
Why hooks are the right place for policy
Hooks are not a new idea, which works in their favor. Git has them. Pre-commit has them. Kubernetes admission webhooks are the same pattern: the platform exposes a well-defined point in its lifecycle, hands control to a script the operator owns, and acts on the answer. Applied to a coding agent, the model decides what it wants to do and the hook decides whether it gets to.
That separation buys four things.
- Policy becomes deterministic. A hook receives the proposed shell command as a string before the shell sees it, and the answer is allow, deny, or ask. A regex on a command line is not subject to jailbreaks. If the policy blocks
rm -rf /
, it blocksrm -rf /
, whatever the reasoning trace looked like on the way there.
- Enforcement teaches. A denial carries a reason the model can read, so the agent corrects course and tries a safe approach instead of hammering the same wall. Developers get a control that behaves like a colleague rather than a permissions dialog.
- Security teams own it directly. The hook is an ordinary process, so you can write it in any language, version it, and sign it. Nobody needs to learn prompt engineering to write a rule, and because policy is evaluated server-side, one update covers every developer.
- You get an audit trail. Every prompt, tool call, shell command, and file read can stream to a SIEM, which answers the question compliance teams have been asking since Copilot launched: what is this thing doing on our laptops, and on whose behalf?
Our differentiation is coverage on one policy plane. Endor Labs wires endorctl ai-audit
to Claude Code and Cursor events, and ships 29 default policies across shell commands, sensitive file access, MCP tool calls, prompts, and skills, plus custom regex rules. The same platform runs the package firewall, so "block malware before it reaches the workstation" and "block the agent from reading .pem
files" are two policies in one console rather than two products with two audit trails. It needs no per-IDE plugin either, which matters when the honest answer to "which agents are your developers using?" is "at least four."
Where would hooks have helped?
What we would advise
Layer, and put hooks at the center. Sandbox the agent so a mistake has a small radius. Put policy at the hook layer so the dangerous action never starts. Put the package firewall in front of the registry so the dependency tree stays clean. Keep EDR underneath, because it covers what hooks cannot see: agents with no hook support, the developer who removed their config, the process that was never an agent at all. Hooks work on cooperative software, so treat the hook configuration as a protected asset.
If you are early, start with logging only. A hook that records every prompt, command, and file read will tell you more in a fortnight than any survey will, and adding enforcement afterward is a config change rather than a re-architecture.
Governance is what lets you say yes to these tools. A security team with deterministic policy and a real audit trail can approve a coding agent on the same terms it approves anything else, which is a considerably better position than debating whether to allow the tool your developers have already installed.
You can see how Coding Agent Governance works, read the technical walkthrough of the hooks integration, or book a demo if you would rather see it against your own policies.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: