AI agent security is knowing which AI agents run in your company, what each one can reach, what it may do without a person, and what it actually did. For most companies in 2026 the agents are not chatbots in a product. They are coding agents on developer laptops: Claude Code, Cursor, Codex, Gemini CLI and the extensions and MCP servers plugged into them. Each one runs with the developer's own access, and each one reads text all day that it may treat as instructions. This page is the map: where the risk lives, the five ways it goes wrong with the incidents that prove it, the four controls that work, and how the frameworks your auditor cares about line up with them. Every section links to the post that goes deeper.
Why does AI agent security happen on the endpoint?
Because that is where the agent is, and where its access is. A coding agent does not run in a sandbox the security team built. It runs in the developer's shell, in the developer's home directory, with the developer's SSH keys, cloud CLI profiles, package registry tokens and every .env file in every cloned repository. When we looked closely at one senior developer's laptop, the agents on it could read forty-six credentials, including production database URLs and cloud keys. Nothing was misconfigured. That is what a developer's access looks like, and the agent inherits all of it.
That inheritance is what makes the agentic endpoint a new category of asset. A laptop used to be a place where a person did work. It is now a place where software with a person's access does work, often unattended, often on the instructions of text it fetched from somewhere else. Network controls see traffic to a model provider and nothing more. Identity controls see the developer, not the agent acting as the developer. The only place the full picture exists is the machine.
What goes wrong? Five failures, five real incidents
Each of these has happened. None required breaking in.
1. The agent follows instructions it read
Everything an agent reads is text it may act on: a README, an issue, a web page, a file a colleague committed. In the GitHub MCP prompt injection found by Invariant Labs, an issue on a public repository carried instructions, the agent read it through its MCP server, and it followed them, pulling data from the developer's private repositories into a public pull request. The agent did what the text said with the access the developer had. What a prompt injection looks like on a laptop walks through the sequence file by file.
2. The agent's reach turns a finding into a loss
A readable credential is a finding. A readable credential plus an agent that can reach the network plus a standing permission to run commands is an incident waiting for its trigger. The forty-six credentials laptop had all three. AI agent security risks ranks the combinations that matter and the ones that do not.
3. A component the agent loads is the attack
Agents are extended by MCP servers, skills, extensions and hooks, and developers install them the way they install packages: quickly, from a marketplace, on a recommendation. Two AI coding extensions with 1.5 million installs quietly sent developers' source files to a remote server. More than a thousand malicious skills were uploaded to an agent marketplace and installed by people who thought they were adding a utility. MCP server security covers what to check before a server is loaded and what to watch after.
4. The person is no longer in the loop
Every agent asks before it runs a command, until the developer tells it to stop asking. On real machines, many have: run any shell command, write anywhere, push to git. Each of those was granted in a session months ago to stop a prompt, and none has been revisited. The agent is now acting without oversight, and the company does not know which agents or which machines. AI agent governance is about the rules a company sets over what an agent may do without asking, and how they are enforced on the endpoint.
5. Nobody knew the agent was there
The official count is two agents. The real count, on every estate we have looked at, is higher, because developers install what makes them productive and nothing asks them to register it. Every incident above happened on a machine somebody would have described as covered. Shadow AI agents explains how to get the real list in fifteen minutes, and why banning them makes it worse.
What are the four controls?
The controls are ordinary security controls applied to a new kind of asset. What follows is how each one works and which of the console's rules evidence it today. The rule names are the real ones; nothing here is a roadmap.
Inventory: know what is there
The sensor reads each agent's own configuration on the endpoint, so it reports every agent, every component and every credential in reach, with no registration step. The rules that make the inventory trustworthy are the ones that report its gaps: endpoint has stopped reporting, sessions running unobserved (the agent runs but nothing observes it) and hook reporting but no inventory scan. Ownership rules close the loop on people: endpoint has no owner, agent signed in as somebody who has left, and owner with unusually many endpoints. Credential reach is its own family: credential in an MCP configuration, credentials an agent can read in a project it works in, and same credential on several endpoints.
Permissions: decide what an agent may do without a person
This is the control with the largest effect for the least work. The rules read each agent's permission set and report agent may run shell commands without asking, the broader agent acts without asking finding, agent safety control turned off, agent runs unattended and long run with nobody at the keyboard. The company's own rules over what an agent may do, record it, ask first, or block, are enforced on the same endpoint through the agent's own hook mechanism, so an agent that should ask does ask. The decision of which permissions are acceptable for which team stays with a person.
Component review: control what gets installed
New MCP servers, skills and subagents can be held for review before an agent loads them, which is a workspace setting the compliance report checks directly. The rules cover the component's provenance and state: unreviewed components, approved component changed, MCP server package not pinned to a version, package published in the last days, package installed from a URL, not a registry, package flagged as malicious, package with a known advisory, component can run commands and reach the network, and component tells the agent to bypass approvals. The tools comparison sets out what this looks like across the products on the market.
Runtime rules: stop the sequence, not the step
A credential read is normal. An outbound connection is normal. A credential read followed by an outbound connection to a destination this endpoint has never used is the exploit. The runtime rules watch for sequences and patterns rather than single events: credential used, then the network, agent acted after instructions arrived in tool output, same injected instructions on several endpoints, remote script piped into a shell, agent wrote to a startup or hook location, data sent to a paste site, file share or webhook, a destination this endpoint has never used, and the behavioural baselines more tool calls than this agent normally makes and more subagents spawned than this agent normally does. Each is a rule that can record, ask or block, and each shows in the console as one attack path with the hop it broke, not as a pile of alerts.
How do the frameworks map onto this?
The EU AI Act puts obligations on deployers, and a company whose developers run agents is a deployer. Article 9 (risk management) is the inventory and the credential and reach rules. Article 12 (record keeping) is the coverage rules that prove the logs are complete. Article 14 (human oversight) is the permissions control, and the setting that holds new components for review. Article 15 (cybersecurity) is component review plus the runtime rules for injection and persistence. Article 26 (deployer obligations) is ownership. Three articles need a person and the report says so by name. EU AI Act compliance for AI coding agents goes article by article.
The OWASP Top 10 for LLM Applications was written for applications built on models, and a coding agent is one. Six of the ten show up directly on a developer machine: LLM01 prompt injection and LLM05 improper output handling are the runtime rules, LLM02 sensitive information disclosure is credential reach, LLM03 supply chain and LLM04 poisoning are component review, LLM06 excessive agency is permissions, and LLM10 unbounded consumption is the behavioural baselines. Three are about an application's own design and are attested by a person. The OWASP LLM Top 10 on a developer laptop takes each risk to the endpoint.
The point of the mapping is that the same evidence feeds both reports, from one inventory, so they never disagree with each other or with what is actually on the machines.
A worked example: one laptop, four controls
A developer's laptop runs Claude Code and Cursor. Inventory finds both, plus three MCP servers, one of which nobody reviewed. Permissions finds that Cursor may run any shell command without asking. Credential reach finds a .env with a production database URL in a project both agents work in. A week later a runtime rule fires: Cursor read that .env and, in the same session, opened a connection to a destination the endpoint had never used. The rule was set to block, so the connection did not happen. The console shows one attack path: the unreviewed MCP server that carried the instructions, the permission that let the agent act, the credential it reached, and the hop where it was stopped. The fix is one permission, one file move, and one component review. The report for the quarter records the finding, the block, and the fix, against Article 15 and LLM01.
Where to start
- Put the sensor on the developer machines and get the real inventory. Everything else depends on it.
- Read the permission findings first. Standing permissions are the fastest fix with the largest effect.
- Turn on holding new MCP servers, skills and subagents for review, so the component list stops growing while you work through it.
- Move the credentials the agents can read out of their reach. Usually one file per project.
- Set the runtime rules to record for two weeks, then to ask or block once you know what normal looks like.
- Run the compliance report at the end of the quarter and keep it. The first audit asks for a period of evidence, not a snapshot.
AI agent security is not a new discipline. It is asset inventory, least privilege, supply chain control and detection, applied to software that acts with a person's access. The difference is that the asset arrived without asking, and the controls have to go where it lives.
Frequently asked questions
What is AI agent security? The practice of knowing which AI agents run in a company, what each one can reach, what it is allowed to do without a person, and what it actually did. For most companies today the agents are coding agents such as Claude Code, Cursor and Codex on developer machines, so the work happens on the endpoint: an inventory of agents and their components, a review of standing permissions, control over what gets installed, and rules that stop a dangerous sequence while it runs.
How is AI agent security different from LLM security? LLM security is about the model and the application around it: what the model says, what it leaks, how it is prompted. AI agent security is about what the software around the model does with the developer's access: the files it reads, the commands it runs, the servers it talks to, the components it loads. An agent can be attacked through its model, but the loss happens through its tools and permissions, which is why the controls are endpoint controls.
Do we need AI agent security if we only use approved tools? Yes, for two reasons. The approved tool is still an agent with the developer's access and a set of standing permissions granted months ago, and one real laptop with only approved agents had forty-six credentials in their reach. And the approved list is rarely the real list: most companies that look find agents nobody registered, running with the same access.
Where should a security team start with AI agent security? Inventory first, because every other control depends on knowing what is there. Then read the standing permissions, because "run any shell command" is the fastest fix with the largest effect. Then hold new MCP servers, skills and extensions for review so the component list stops growing while you work through it. Runtime rules come last, once you know what normal looks like.