The endpoint knows which binary ran. It does not know what the agent did.

An agent on a developer's laptop force-pushes to your main branch on a Friday afternoon.

Ask the endpoint what it saw.

It saw a signed, approved, allow-listed binary that the developer is entitled to run, making an ordinary outbound TLS connection to a host it connects to forty times a day. Every one of those facts is correct, and none of them is the event you care about.

The event you care about happened somewhere else entirely: at your git host, where a credential was presented and a protected branch was overwritten.

What endpoint security is genuinely excellent at#

This is not a takedown. Endpoint tooling is one of the most mature categories in security and it answers its question extremely well: what software is running on this machine, is it what it claims to be, and is it behaving like malware.

For AI that gets you something real. Discovery of tools nobody registered. An inventory of what is installed. The ability to allow or deny a piece of software wholesale. If your problem is "we have no idea what our developers have installed," an endpoint sensor is a good answer and probably the fastest one to deploy.

The mismatch is not quality. It is that the question has moved.

The plane the risk actually lives on#

Classic endpoint risk is: untrusted software does something on this machine.

Agent risk is: trusted software, running with legitimate credentials, doing something to a system somewhere else.

Every word of that shifts the ground. The binary is Claude Code or Codex or Cursor, which you approved. The credentials are the developer's, which you issued. The machine is fine throughout and stays fine. The damage is a state change on a resource, and the resource is not on the endpoint.

Which puts the two things you most need to know structurally out of reach. Which repository, which branch, which database, which record sits inside an encrypted session to a service the sensor is not party to. And who approved it is a question about your policy, not about the process table.

You can watch the process do something. You cannot see what it did.

Three places agents run where there is no endpoint#

Even where the model works, it only covers machines you manage. A growing share of agent activity is not on one.

CI. An agent in a pipeline runs on a container that exists for ninety seconds. No sensor, no enrolment, nothing to manage. It still holds a deploy credential.

Servers. A scheduled agent doing nightly work runs on infrastructure, not on a laptop.

A vendor's cloud. The agent your CRM turned on last month runs in the vendor's own environment. No machine of yours is involved at any point. You cannot install anything on it, ever, and neither can anyone else.

That third one is not an edge case. It is the fastest-growing category of AI in most companies, precisely because nobody has to deploy it, and it is the one an endpoint strategy can never reach. That is a property of the architecture, not a gap in somebody's roadmap.

The coverage cost nobody prices#

There is also a practical problem that shows up in month two.

Endpoint coverage means enrolling machines. Every developer laptop, every contractor, every new hire, every BYOD exception. That is a device management programme, and those take quarters and political capital, because you are asking to install software on people's computers.

Governing at the credential and at the resource asks for none of it. You issue a key and you gate a door, and the developer keeps their laptop, their terminal and their setup. A contractor on an unmanaged machine is covered from their first request, because the coverage rides on company credentials reaching company systems rather than on company software installed on a company device.

That is why this reaches things an endpoint cannot, and why one platform engineer can try it in an afternoon instead of booking a rollout committee.

Where the refusal should happen#

The strongest place to stop an action is the place it arrives.

At the git host, at the API gateway, at the database, at the credential itself. A refusal there is not a check that can time out or be routed around: the key does not open that door, so the door does not open. It holds whoever wrote the agent and wherever it is running, including on a cloud you will never touch.

The difference in one line: the endpoint governs which software may run; the credential and the resource govern what any of it may do.

What we are not saying#

We are not an endpoint replacement, and if someone tells you their agent-governance product replaces your EDR, be careful.

Malware is still malware, and the tooling that catches it is not the tooling that decides whether an approved agent may push to main. Most serious companies will run both. They answer different questions, and ours is: what did it do, who approved it, can you prove it.

The one place to push back is on coverage claims. An endpoint story cannot cover CI, servers or vendor-cloud agents, and no amount of sensor quality changes that, because there is nothing to install.

If your AI risk is "which tools are on our machines," start with the endpoint. If it is "what are those tools doing to our systems, and who said yes," that is a different plane.