can a company control what ai coding agents do on employee laptops

Why Device Management Alone Does Not Cover It

Companies already know how to manage laptops. Jamf, Intune and Kandji push configuration profiles, install software and enforce disk encryption. What they cannot see is what happens inside an AI coding agent session: the agent reads a repository, decides to run terraform apply or aws route53 change-resource-record-sets, and executes it with whatever credentials the developer has loaded. Nothing in device management evaluates that decision.

The missing layer is a fleet-wide policy that is pushed centrally, like a device profile, but evaluated per agent action, like a firewall rule. It answers a common question from infrastructure leads: what tool calls are our engineers’ agents actually making?

Device Management Versus Agent Policy

The two are complementary. Device management is a good way to install and keep the policy client present on every machine; deploying with Jamf or Intune covers that. The agent layer is what actually reads rm -rf, kubectl delete or a Python script calling boto3 and decides.

The Five Parts of a Working Setup

1. A local enforcement point. A hook in each agent harness hands every gated event to a local evaluator before the agent proceeds. In Failproof this is the failproofai CLI plus the failproofaid daemon that failproofai config installs.
2. Policies as code. Rules written in JavaScript or TypeScript, versioned, testable, and evaluated the same way across harnesses. See policy-as-code.
3. Central deployment. Admins publish policy versions and deploy them to enrolled machines, first in observe mode, then enforce. See the rollout guide.
4. Scoping. Repository rules live in project-scope policy files; central deployments target machines; managed deployments add persona assignment, such as stricter rules for on-call engineers. See different rules per team.
5. Telemetry. Sessions and decisions from every machine in one place, so an incident can be traced to a session and a machine. See what agents did.

What Happens on One Tool Call

Deterministic policies evaluate on the machine, so a decision does not wait on a network round trip; our engineering write-up measured the daemon path at about 0.7 ms p50. The central side deploys policies and receives telemetry. The exception is optional Jev review, which makes one model request per reviewed call.

What Agent Policy Is Not

• Not a sandbox. A sandbox limits what a process can touch. A policy decides whether a specific action is allowed. Most teams want both; see hooks vs sandbox vs managed settings.
• Not a replacement for IAM. If a developer’s SSO session can delete production DNS, a policy lowers the chance an agent does it, and IAM decides whether it is possible at all.
• Not a ban on agents or a mandated toolchain. The point is to let developers keep their IDE, terminal and harness of choice while the same rules apply to all of them.
• Not complete on every harness for every event. Pre-tool blocking is verified on all twelve harnesses Failproof supports; stop, prompt and post-tool gates vary, and on Hermes an instruct does not stop the call. See one policy across agents.

How to Check a Vendor’s Claim

1. Ask an agent to run a blocked command directly, then through a shell script it writes itself. Both should be denied, or the vendor should tell you which one is not covered.
2. Stop the local evaluator and retry. The call should fail closed with a visible reason, not silently run.
3. Ask the agent to disable or pause the policy client. It should be refused.
4. Find the blocked call in the console, attributed to the right machine, policy and session.