Guide
How do enterprises secure AI coding agents running on developer laptops?
Updated
Short answer
Keep EDR, vendor managed settings pushed by MDM, sandboxing and scoped credentials, then add a check on every agent action before it runs. None of those controls knows what the developer asked the agent to do. Run the check on the laptop, outside the agent, at its pre-execution hook, judging each command, file edit and push against the session's intent.
Why agents aren't like other endpoint software
A normal app does what its code says. A coding agent decides what to do next, over and over, inside one session.
Agents average 145 actions per session, and long sessions go past 1,000. Each action is a shell command, a file edit or a push, picked by a model that read your repo, maybe a web page and maybe a poisoned README.
People can't review that many. In Anthropic's controlled study of 1,053 testers, human review caught just 13.6% of dangerous commands. The approval prompt is a weak control, and your developers already know it.
The laptop is already a supply-chain target
On October 29, a malicious Claude Code extension on Cursor was live for about 11 hours, and up to 5,000 developers were exposed. It tried to add an attacker-controlled SSH key, enable SSH access and open a reverse tunnel. It set up persistence through a macOS LaunchAgent or a Windows scheduled task.
That code arrived as developer tooling and ran on the developer's laptop. To be honest about it, a pre-execution check on agent actions wouldn't have stopped this one, because the code never went through the agent. Extension review, pinning and EDR are what cover that path, and they stay on the list.
What each control catches and misses
Be fair to what you already own. Each one does a real job.
| Control | What it's for | What it doesn't cover |
|---|---|---|
| EDR | Known malware, suspicious persistence, process behavior | What the developer asked the agent to do. An agent running `git push` is a trusted process doing a normal thing |
| MDM | Getting software and config onto every laptop | Judging actions at runtime. It delivers policy and doesn't evaluate it |
| Vendor managed settings | A fleet-wide floor: managed settings sit above every user, project and local value | Each vendor has its own settings and rules, and none of them looks at intent |
| Sandboxes | An OS boundary around shell commands | Shell commands only. File tools, MCP servers and hooks run outside it, and reads of `~/.ssh` and `~/.aws/credentials` are allowed by default |
Keep all of them. None of them answers the question security leaders keep getting asked: did this action match what the developer asked for?
What the missing check looks like
The same command can carry two intents. A `curl` to a package registry during a build is fine. A `curl` with an API key in the body, right after the agent read a `.env` file nobody asked it to open, is not.
So the check has to happen while the action is still a proposal, which means at the agent's pre-execution hook. It has to run outside the agent so the agent never grades its own homework. And it has to judge the action against the session's intent rather than match it against a list of banned strings.
Where Harden fits
Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. No command, file edit or push runs until Harden has checked it against the session's intent.
Nothing leaves the machine. Decisions are made locally, in about 28 ms.
The enforcement path is deterministic: Harden parses the pending command and traces data from its source to its destination. If a secret reaches a network call, Harden acts. If the check can't run, the action doesn't run.
The possible verdicts are allow, block, ask, redact (a safe rewrite of the call) and log only. On a block, the agent gets the reason and can try again a safe way. One policy covers every agent that exposes a pre-execution hook. Details are on the AIF trust page and the security teams page.
It's one layer on top of least privilege, scoped credentials and egress policy. It won't contain code that's already malicious. Exfiltration split across several separate calls is the hard case.
Rolling it out
Push it with the MDM you already run, like any other agent on the fleet.
Start watch-only. Harden logs what it would have decided and blocks nothing, so your team sees what agents actually do before you enforce anything. Every decision is saved as a Record you can export to your SIEM.
A checklist you can forward
- List which agents and editor extensions run on laptops, and who installed them.
- Push vendor managed settings through MDM as the floor, and turn on sandboxing where it's supported.
- Pin extension versions and review updates. Treat marketplace publishing as a supply-chain path.
- Scope credentials so a stolen key can't reach much.
- Add a check that runs before each agent action, on the laptop and outside the agent, and judges the action against intent.
- Run it watch-only first, then enforce on secrets, destructive commands and pushes.
- Require fail-closed behavior and local decisions.
- Export Records to your SIEM for audit.
FAQ
Related questions
Isn't EDR enough for coding agents?
EDR is good at catching known malware and suspicious persistence. It doesn't know what the developer asked the agent to do, so a harmful command from a trusted agent process can look normal. Keep EDR and add a check on each agent action.
Does the check slow developers down?
Harden decides on the laptop, in about 28 ms (P99 about 70 ms), so nobody waits on a network round trip. In our own internal use, 0.25% of 24,809 decisions were wrong hard blocks.
Can we run agents safely on laptops with just vendor managed settings?
Managed settings are a solid floor, and you should deploy them. But each vendor has its own settings and rules, so you end up with a separate policy per agent and nothing that looks at intent.
How do we start without breaking developer workflows?
Push Harden with your MDM and start in watch-only mode. It logs what it would have decided and blocks nothing, so you can tune policy before you enforce it.
What does it cost?
Full Enterprise access is free for 60 days, with unlimited developers and no commitment. After that it's $20 per user per month, flat per developer. Start free at harden.run.