[Back to Blog](https://certiv.ai/blog/)
If you remember your high school chemistry, you might remember students learn the rule before they touch a beaker. Add acid to water, never water to acid. The ingredients are identical either way. Pouring them in one order gets a safe solution, but reverse it and the mixture can boil and spit acid back at you. No safety check on the bottles would ever catch the difference. The danger isn’t in either bottle. But mix up the sequence and you might run for the eyewash stations.
Agentic AI has the same problem. Every action an agent takes can pass inspection, and the incident still happens. The risk was never in a single step. It was in the order.
If a developer installs an AI coding agent on a Tuesday afternoon, nobody would file a ticket. Nothing on its face looks wrong. But by Thursday the agent is reading files, running shell commands and calling the network on their behalf all day long. Being the astute IT manager, you might run security and have a decent endpoint tool in place already, saying everything’s fine. It reports nothing. It isn’t looking at the right thing.
What EDR was built to watch #
Endpoint Detection and Response (EDR) watches processes. It asks whether a program is known, whether it behaves like malware, whether it is touching memory it shouldn’t and so on. To its credit, this workflow has worked well, since malware is a program that shouldn’t be there.
But AI agents are a different species. Someone installs one on purpose, it holds all the right accreditation and keys given by its developer, and the agent in turn runs as ‘the developer’, which allows it to read files and run commands. That is the job it was instructed to do. Your EDR will certainly see its activity, but only be able to discern that at the surface level it is a trusted process doing ordinary things. Nothing fires, and nothing should.
The sequence is the gap #
To make this a little more concrete, say you ask an agent to fix a failing test. Partway through, it runs cat ~/.aws/credentials, the plaintext file where the AWS CLI keeps a long-lived access key and secret for your default profile. A few steps later, it spawns curl and sends an HTTPS POST to a domain registered three days ago. The body is a base64 string, roughly the length of those two keys.
Now, look at each step alone and how they were permitted. The file belongs to the user the agent runs as and the outbound HTTPS is open. There are many, many developer machines that spawn curl, some hundreds of times a day. But a test fix has no reason to need your cloud credentials, and equally, it also has no reason to talk to a stranger’s server right after reading them. The problem lies within the order of the actions. A tool that judges each event on its own never asks whether that order makes sense for the task. It sees one trusted process, and that process implies that it is behaving normally. This can go wrong without any kind of new attacker. A bad instruction hidden in a web page or a package readme, or even a plain mistake by the model, would be enough.
What it takes to close the gap #
You need something on the endpoint that sees each action an agent takes and decides what to do with it before it runs. We call it endpoint security for AI agents. It doesn’t replace EDR, but it does sit alongside it as a separate layer. Our solution for this layer is called Scout.
At that point there are only a few answers worth having:
- Allow it and keep a record.
- Hold it until a person approves.
- Stop it.
- Hold the action back and tell the agent why, so it can pick a safer route.
That last option matters more than it sounds. Agents are good at working around a flat refusal, but they respond well to a clear reason. In the example above, the credentials read can be held back with guidance, and the agent carries on with the test.
Teams usually begin with coding agents, since that is where the most autonomy and the most access already sit. The mechanics of deciding before the action runs are covered in pre-execution policy enforcement.
Where this leaves your EDR #
Does this mean you should throw away your EDR? No, of course not. EDR still does the job it was built for. But agentic activity needs a different kind of visibility, one tied to intent with control to hold back that action before anything executes. Scout covers the gap by adding a second view of the same laptop which reads actions in sequence rather than processes actions one at a time.
The same goes for Microsoft’s tooling. Defender for Endpoint can now discover agents on Windows and macOS endpoints and score how risky each one looks, and it feeds that inventory to Agent 365 and Intune. Scout complements that by deciding, action by action, what a running agent is allowed to do before it does it. Together, they answer two different questions: which agents are on your machines, and what each one is allowed to do right now. To see how Scout handles the enforcement side, take a look at the platform. In a lab, the rule is taught once and trusted forever. With agents, it has to be enforced on every pour.
Frequently asked questions #
What is endpoint security for AI agents?
It means deciding on an agent’s actions on a laptop before they run, based on whether they fit what the user asked for. It works alongside EDR.
Can EDR see AI agent activity?
Partly. It sees the process and the file and network activity around it. A trusted agent doing allowed things looks normal to it.
How do you get AI agent visibility on endpoints?
You need something on the endpoint that sees each agent action, not just the process. Scout does that and records every action it decides on.
Does this replace EDR?
No. EDR covers the process layer and Scout covers the action layer. You keep both. They are watching for different things.
If you would like to see this on a real laptop, book a demo.