AI agent security is the practice of seeing and controlling what the AI agents on your developers' machines can read, run and reach. It matters because those agents act with a developer's full access, and they can be steered by text they read in a web page, a file or a tool result. This article explains what the agentic endpoint is, why traditional endpoint tools miss it, and what a practical approach to securing AI agents looks like.
What is an agentic endpoint?
An agentic endpoint is any machine running an AI coding agent that can act on its own: Claude Code, Cursor, Codex CLI, GitHub Copilot, Gemini CLI and the rest. Three years ago a developer laptop ran an editor, a terminal and a browser, and a person drove every step. It still runs those, but now the terminal runs an agent that reads files, runs shell commands, installs packages and calls the network without a person pressing a key for each action.
That shift turns the laptop into a new security boundary. The agent is software that acts on behalf of a person, with that person's access. It reads the project's .env file because the task needs it. It runs a build because the task needs it. It fetches a web page because the question needs it. Each of those is normal, and each is a path an attacker can use.
Why do EDR and antivirus miss AI agent risk?
Endpoint detection and response tools were built to catch malware: a known bad binary, or a known bad pattern of behaviour. An AI agent is neither. It is a trusted, signed program doing exactly what it was designed to do. Nothing about the binary is malicious.
The harm comes from the instruction the agent was told to follow, and that instruction arrives as ordinary text: a sentence in a web page, a comment in a code file, a line in a package README, a string in a tool result. No malware signature matches a sentence, so an EDR sees a normal process reading a normal file and calling a normal command. The action is dangerous only in context, and the context lives on the endpoint.
This is why AI agent security is a distinct problem. It is not about blocking bad software. It is about understanding what a good program is being asked to do, and stopping the actions that cross a line. What a prompt injection looks like on a laptop shows one such action step by step.
What can an AI agent on a laptop actually reach?
An agent runs with the developer's identity, so it can read whatever the developer can read. On a typical machine that includes:
- Credential files: .env files across every project, cloud CLI profiles, SSH keys, and the OS keychain.
- The source code of every repository the developer has cloned.
- Standing permissions the developer granted so the agent no longer asks, such as the ability to run any command, push to git or write anywhere.
- Every MCP server, skill, extension and package the agent loads, some of which were installed without review.
One real developer machine, scanned, held forty-six credentials that its agents could read. Not one was misplaced. That is simply what a working laptop looks like, and it is exactly why a single prompt injection can turn into a real loss.
The three questions AI agent security has to answer
A practical programme for securing AI agents comes down to three questions, and everything else is a way of answering one of them.
Reach: what agents run on our machines, and what can each one touch? You cannot protect what you cannot see. The first step is an inventory of every agent, server, skill and package on every endpoint, and for each agent, the credentials, permissions and systems it can reach.
Posture: what is true about that estate that should not be? A credential an agent can read but nobody tracked. A server nobody reviewed that loads on every session. A standing permission the workspace forbids. These are issues you rank and fix by cause, not one machine at a time.
Threats: what did an agent do that a person needs to look at? A prompt injection acted on. A credential passed to a tool and then sent to a paste site. A destructive command. A run outside the agent's normal baseline. These are events, caught as they happen.
Reach, posture, threats. If you can answer those three across your fleet, you have the shape of AI agent security.
Why the answer has to come from the endpoint
It is tempting to solve this at the network, with a proxy that watches traffic. A proxy sees that a request went out. It does not see why. Only the endpoint sees the agent's own configuration, the tool call that read the credential, the instruction in the file that triggered the command, and the moment the agent decided to act.
A sensor on the endpoint reads the agents' own configuration, checks each tool call as it happens, and can stop the harmful action before the process starts. It reports names and hashes to a console for the security team, while credential values and the contents of conversations never leave the machine. That last point matters: securing AI agents cannot mean shipping your developers' secrets and source to a third party.
How do you start securing AI agents?
You do not need to boil the ocean. A sensible first week looks like this:
- Inventory every agent and what it can reach, so you have a baseline instead of an assumption.
- Find the credentials your agents can read, by name, and decide which ones a person should be watching.
- Turn on detection for the actions that matter: prompt injection acted on, credential movement, destructive commands, safety controls disabled.
- Contain anything unreviewed, so a new server or skill is held until someone approves it.
- Map what you find to a compliance framework, so the work counts toward the audit you already owe.
The recent supply chain incidents make the case for moving now. In one, more than a thousand malicious skills were uploaded to an agent marketplace. In another, two coding extensions exfiltrated source code and API keys from 1.5 million developers. A self-spreading package worm exposed about fourteen thousand secrets across nearly five hundred organisations. These are not hypotheticals; they are the reason AI agent security is a category rather than a footnote.
The estate grows whether you watch it or not
The reason to start now rather than next quarter is that the agentic estate on your machines is expanding on its own. Every developer who adopts a new agent, installs a new MCP server, or adds a skill from a marketplace enlarges the surface without anyone filing a ticket. The tools are designed to make this frictionless, which is exactly why the security picture drifts out of date within days.
That is the difference between AI agent security and a one-time audit. An audit tells you what was true last month. What you need is a live view: which agents run today, what each can reach today, and what any of them did in the last hour that a person should see. The estate is dynamic, so the control has to be continuous.
One machine can be checked by hand. A security engineer can sit with a developer, open the agent's configuration, list the MCP servers, read the permissions and write down what the agent can reach. That takes an hour and it is true for that afternoon. It does not tell you which of the other three hundred laptops have the same agent, which of them added a new MCP server yesterday, whose agent has been running unattended since Tuesday, or which endpoints have quietly stopped reporting at all. An estate of agents needs the same thing an estate of servers needed: a sensor on every machine and one place where the answers are kept, dated, for the next audit.
If you cannot say today how many AI agents run on your developers' machines, that is the first number to get. Join the launch list and be first to run it on your own endpoints.
What AI agent security is not
It is worth naming the things this is not, because they get proposed and they do not work. It is not blocking AI agents; developers are more productive with them, and a ban simply drives them to unmanaged machines. It is not a network proxy alone; the proxy cannot see the agent's configuration or the instruction that triggered an action. It is not a policy document; a rule nobody can enforce on the endpoint is a wish. And it is not sending your developers' code and secrets to a vendor to be analysed, which trades one exposure for another. AI agent security is the specific, endpoint-level work of seeing the agents, knowing their reach, catching the dangerous action, and containing the unreviewed.
How ZYBE handles this
ZYBE puts a sensor on each developer machine that reads the agents' own configuration, so the inventory of agents, MCP servers, skills and permissions appears the moment it is installed with nothing for developers to register. The console shows every agent by endpoint and owner, and the coverage rules say where the picture is incomplete: endpoint has stopped reporting and sessions running unobserved. Reach is shown per agent, with credentials an agent can read and data access combined with egress as findings, and where the pieces join up the console raises findings combine into an attack path rather than four separate alerts. Credential values and conversation contents never leave the machine; the sensor reports names, counts and hashes.
Join the launch list: first access when ZYBE opens, and what we find on real laptops before then.
Frequently asked questions
Why is EDR not enough for AI agents? EDR looks for malware. An AI agent is a trusted program; the danger is the instruction it follows, which arrives as plain text no signature matches. The action has to be judged in context, on the endpoint.
Can an AI coding agent access my credentials? Yes. It runs with the developer's access, so it can read .env files, cloud profiles, SSH keys and the keychain, along with any system those credentials open.
How do you secure AI agents without slowing developers down? A sensor reads the agents' own configuration, so there is nothing for developers to register. It blocks only the specific dangerous action, and it keeps credential values and conversations on the machine.