The OWASP Top 10 for LLM Applications was written for software built on language models, and an AI coding agent is exactly that: a model, a set of tools it can call, and a stream of untrusted text it reads all day. Most write-ups of the list talk about chatbots and RAG pipelines. This one takes each of the ten risks to the place where most companies actually run models today, a developer laptop with Claude Code, Cursor or Codex on it, and asks three questions: what does the risk look like there, what evidence shows it, and what still needs a person. It is the second in a series on frameworks; the first covered the EU AI Act.
Why the endpoint, not the app?
Because the app is where the risk is written about and the endpoint is where it happens. A company might have one internal LLM application under review. It has hundreds of agents on developer machines, each with the developer's access: the cloned repositories, the .env files, the cloud CLI profiles, the SSH keys. One real laptop had forty-six credentials its agents could read. Whatever the OWASP list says about an application applies to every one of those agents, and the shadow ones most of all.
LLM01: prompt injection
The risk that everything the agent reads is text it may treat as instructions. On a laptop, the untrusted text is a README in a dependency, an issue pulled through an MCP server, a web page fetched for context, a file in a repository someone else committed. The GitHub MCP incident is the reference case: an issue carried instructions, the agent read it and followed them, and private repository data went into a public pull request.
Evidence: injected instructions detected in what the agent read, and whether the agent acted on them afterwards. The second half is what matters. A detection with no action is noise. A detection followed by a credential read or an outbound connection is an exploit in progress, and the console shows it as one attack path, not two alerts.
LLM02: sensitive information disclosure
The risk that credentials and personal data pass through the model. On a laptop this is not theoretical. Agents read .env files because the project needs them. Some developers paste a token into the agent's own configuration so it stops asking. Cloud profiles sit in the home directory where every agent's working directory can reach them.
Evidence: every credential an agent can read, whether it is in the agent's configuration or merely in reach, whether it was read in a session, and whether a read was followed by data leaving the machine. Seven rules cover this, and the fix for most findings is moving one file.
LLM03: supply chain
The risk that a model, plugin, tool or package came from somewhere it should not have. For agents, the supply chain is the MCP servers, skills, extensions and hooks the developer installs, plus the packages the agent installs on the developer's behalf. Two AI coding extensions with 1.5 million installs exfiltrated source files. More than a thousand malicious skills were uploaded to an agent marketplace.
Evidence: the component inventory per endpoint, matched against advisories, with its age, whether it was pinned, whether it was reviewed before use, and whether an approved one changed since. Eleven rules, and the setting that matters most is holding new MCP servers and skills for review so the list stops growing while you work through it. The MCP server piece goes into the details.
LLM04: data and model poisoning
The risk that what the model is instructed by has been tampered with. On a laptop the model itself is remote and out of reach, but the instructions are local: the project's agent rules file, the hooks that run on every session, the components that inject their own prompts. A hook that survives the session, or a component that quietly turns off the agent's approval step, is a poisoned instruction set.
Evidence: unreviewed components, writes to persistence locations, hooks that persist, and any component that bypasses approvals. Five rules.
LLM05: improper output handling
The risk that model output is executed without validation. An agent's output is commands, and the validation step is the developer's approval. When a permission says "run any shell command", the validation is gone. The same risk covers an agent whose safety controls were switched off, which several ship with an option to do.
Evidence: permissive permissions per agent, safety controls disabled, and injection followed by action. Four rules, overlapping with LLM01 and LLM06 on purpose, because the same finding is evidence for each.
LLM06: excessive agency
The risk the list itself calls out as the one that turns the others into incidents: an agent with more functions, permissions or autonomy than the task needs. On a laptop this is the standing permissions story. "Write anywhere." "Push to git." "Run any command." Granted in a session months ago to stop a prompt, and never revisited. Add the reach of the developer's account and the combination is what makes a small injection a large loss.
Evidence: the permission set per agent per machine, the combinations of reach that matter (a readable production key plus network access), shell auto-allowed, destructive commands, privilege escalation, and unattended runs. Eight rules, and the console's rules a company sets are enforced on the same endpoint, so an agent that should ask does ask.
LLM07, LLM08, LLM09: the three that need a person
System prompt leakage, vector and embedding weaknesses, and misinformation are risks of an application's own design. Whether a system prompt holds a secret, whether a retrieval store enforces access control, whether output is verified before it is relied on: none of those can be read from a developer laptop, because they live in the applications the company builds, not the agents it runs. The compliance report says so, assigns each to someone by name, and takes an attestation. Pretending a sensor can see them would be the misinformation risk in action.
LLM10: unbounded consumption
The risk that an agent runs without a bound on what it consumes. On a laptop the cost is usually not the bill. It is the loop: an agent that spawns sub-agents that spawn sub-agents, a burst of tool calls with no human in between, a run that continues unattended for hours. These are the behavioural signals that something changed, and they are also the earliest sign of the other nine.
Evidence: tool call bursts, spawn bursts, and autonomous runs, against each agent's own baseline. Three rules.
A worked example: three risks, one finding
A developer's Cursor has a standing permission to run any shell command (LLM06). The project it works in has a .env with a production database URL in reach (LLM02). A dependency's README carries an instruction to run a setup script that reads that file and posts it to a URL (LLM01, LLM05). The sensor reports the permission, the credential and the injection as three findings grouped by cause, and the runtime rule that blocks a credential read followed by egress stops the script before the post. The compliance view marks LLM01, LLM02, LLM05 and LLM06 as present on that endpoint, with the fix beside each. The fix is one permission and one file move.
What the auditor gets
A dated report against the ten, with six assessed from evidence, one from runtime signals, and three from attestation with a name on each. The count of endpoints in scope, the findings open and closed in the period, and the exceptions. Because the same rules feed the EU AI Act report, the two are produced from one inventory and never disagree with each other.
Where to start
- Read the LLM06 findings first. Standing permissions are the fastest fix and the one that shrinks every other risk.
- Move the credentials LLM02 finds out of the agents' reach. Usually one file per project.
- Turn on holding new MCP servers and skills for review, so LLM03 and LLM04 stop growing.
- Assign LLM07, LLM08 and LLM09 to someone by name and have them attest.
- Run the report and keep it. The next customer questionnaire that mentions OWASP has an answer ready.
The OWASP LLM Top 10 is not a new programme for a company that runs coding agents. It is the same inventory, permissions and monitoring the security team wants anyway, with the ten headings a customer will ask about attached.
Frequently asked questions
Does the OWASP Top 10 for LLM Applications apply to AI coding agents? Yes. The list was written for applications built on language models, and a coding agent is one: a model, a set of tools it can call, and a stream of untrusted text it reads. Six of the ten risks show up directly on a developer machine as things a sensor can find. Three concern the application's own design and are assessed by a person. One, unbounded consumption, is a runtime signal.
Which OWASP LLM risks matter most for coding agents? LLM01 prompt injection, LLM02 sensitive information disclosure and LLM06 excessive agency, because they combine. An agent reads a file that carries instructions, the instructions point it at a credential it can read, and a standing permission lets it act on what it found without asking. Each risk alone is a finding. Together they are the incident.
What evidence does an auditor want for the OWASP LLM Top 10? For each of the ten, whether the risk is present on any endpoint and what was done. In practice: the injection detections and what the agent did next (LLM01, LLM05), the credentials in reach of an agent (LLM02), the components loaded and whether they were reviewed and pinned (LLM03, LLM04), the standing permissions per agent (LLM06), the tool call and spawn rates (LLM10), and a signed attestation for the three risks that need a person (LLM07, LLM08, LLM09).
Is the OWASP LLM Top 10 a compliance requirement? No. It is a risk list, not a regulation. It matters because customers, auditors and insurers use it as the checklist for anything with a model in it, and because the EU AI Act's Article 15 asks for resilience to exactly the attacks it names. A company that can show its state against the ten has an answer ready for all three.