EU AI Act compliance for AI coding agents comes down to one sentence: a company whose developers run agents is a deployer, and a deployer has to know what the agents are, keep a person able to stop them, record what they do, protect them from being turned against the company, and report it when that fails. Those five duties live in Articles 9, 12, 14, 15 and 26. This article is for the CISO or security architect who owns the audit, and it goes article by article: what each one asks when the AI system is an agent on a developer laptop, what evidence satisfies it, what the endpoint can produce on its own, and what still needs a person.
Why are AI coding agents in scope at all?
Because the Act's definitions do not care what the software is for. An AI system is anything that infers from its input how to produce outputs that influence an environment, and a coding agent that reads a repository and runs commands is a clean example. A deployer is anyone using an AI system under their own authority in the course of business. The company did not build Claude Code, Cursor or Codex, so it is not a provider. It let its developers run them on company machines, so it is a deployer of every one, including the ones it does not know about.
The deployer obligations are the ones that bite here, and they are not abstract. The agent runs with the developer's access: every cloned repository, every .env file, the cloud CLI profiles, the SSH keys, the package registry tokens. One real laptop had forty-six credentials its agents could read. An agent with that reach is what the Act means by a system that needs oversight, whether or not its category appears in Annex III.
Article 9: risk management
Article 9 asks for a risk management system that runs for the whole life of the AI system: identify the risks, estimate them, adopt measures, and check the measures work. For agents on developer machines, the risks have names.
- A credential written into an agent's configuration, or readable by the agent in a project it works in.
- A component the agent loads, an MCP server or a skill or an extension, with a known vulnerability.
- The combination of reach that turns a finding into a loss: an agent that can read a production key and also reach the network.
- A concrete attack path across an endpoint, from a file the agent reads to a system it can touch.
- An MCP server talking over plain HTTP, or a local model exposed on the network.
Evidence for Article 9 is the finding list itself, dated, with the state of each: found, owned, fixed. The sensor produces seven of these rules today, and the console groups them by cause so the fix is beside the finding. What stays manual is the judgement of what is acceptable: the risk register still needs a person to sign it.
Article 12: record-keeping
Article 12 asks for automatic logging of events over the system's lifetime, enough to trace what it did. The failure mode for agents is silence: a machine that stopped reporting, an agent whose sessions run without a hook in place, a coverage gap where the developer installed a new agent the sensor has no view into.
Evidence is the log of every agent session, tool call and component change, and just as important, the list of endpoints and agents that should be logging and are not. The three rules here (sessions with no instrumentation, endpoints not reporting, hook-only installs) are the ones that tell an auditor the records are complete rather than merely present.
Article 14: human oversight
Article 14 is the article a CISO should read twice, because it is the standing-permissions story. The system must be designed so a person can understand what it is doing, decide not to use it, intervene, and stop it. An 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 is a permission that removes the person from the loop, granted in a session months ago and never revisited.
Evidence for Article 14 is the list of standing permissions per agent per machine, the components that were loaded without review, the agents that ran unattended, and any case where a safety control the agent ships with was switched off. Six rules cover it, and the rules a company sets over what an agent may do without asking are enforced on the same endpoint. What stays manual is the decision of which permissions are acceptable for which team.
Article 15: accuracy, robustness and cybersecurity
Article 15 asks that the system be resilient to attempts by third parties to alter its use or behaviour by exploiting its vulnerabilities, and it names data poisoning and adversarial input directly. For an agent, adversarial input is prompt injection, and the vulnerability is that everything the agent reads is text it may treat as instructions.
The incident that makes this concrete is the GitHub MCP prompt injection found by Invariant: an issue filed on a public repository carried instructions, the agent read the issue through its MCP server, and it followed them, pulling data from the developer's private repositories into a public pull request. Nothing was broken into. The agent did what the text told it, with the access the developer had.
Evidence for Article 15 is detection of injected instructions in what the agent reads, the components matched against advisories and read for hidden instructions, and the runtime patterns that show an exploit in progress: a credential read followed by an outbound connection, a pipe from a download into a shell, a write to a persistence location, a hook that survives the session. Nine rules cover this article, and it is the one where MCP server security does most of the work.
Article 26: obligations of deployers
Article 26 is the article that names the company. Use the system in line with its instructions, assign oversight to people with the competence and authority to do it, monitor its operation, keep the logs, and inform affected workers. Most of it is impossible without an inventory, and the inventory is where most companies fail before they start.
Evidence is the estate itself: every endpoint with an owner, every agent with an account, and the exceptions that an auditor will ask about first. An agent signed in as someone who has left the company. An account nobody recognises. An endpoint with no owner, or one person with a dozen. An agent configured but not installed, or an endpoint still on its default policy. Seven rules, all of which are the difference between a list and a defensible one. Finding every agent takes fifteen minutes with a sensor, and the fifteen minutes is where Article 26 begins.
Articles 72 and 73: monitoring and incidents
Article 72 asks for monitoring after deployment, and Article 73 for reporting serious incidents without undue delay. For agents, monitoring means the behavioural signals that something changed: a destination the agent never talked to before, a burst of tool calls, a credential used that had only ever been readable, activity at three in the morning, an MCP server used minutes after it was installed. Five rules cover Article 72. Article 73 has one, and it is blunt: a critical detection that has sat unhandled past the reporting window.
What still needs a person
Three articles are assessed by attestation, not evidence, and the report says so by name. Article 4 asks that staff using AI systems have sufficient AI literacy, which is training, not telemetry. Article 13 is the provider's duty to give deployers instructions, so the company's part is to have read them. Article 50 covers transparency to people interacting with AI, which for a coding agent used internally is mostly a policy statement. An honest compliance report marks these as manual and records who attested to them and when.
A worked example: one laptop, one finding, one article
A senior developer's laptop runs Claude Code and Cursor. Cursor has a standing permission to run any shell command. A project on the machine has a .env with a production database URL, and the agent's working directory includes it. The sensor reports three findings: a readable production credential (Article 9), a shell permission that removes the person from the loop (Article 14), and the reach combination of both on one endpoint (Article 9 again, and the path Article 15 is worried about). The fix is a conversation with one developer and a rule that holds shell permissions for review. The report shows the finding opened on Tuesday and closed on Wednesday, which is what a risk management system that works looks like on paper.
What the auditor gets
A dated report, per framework, with each article assessed from evidence where the sensor can produce it and attested by name where it cannot. For the EU AI Act that is seven articles from evidence and three from attestation, with the count of endpoints in scope, the findings open and closed in the period, and the exceptions. The compliance view in the console builds it from the same data the security team works from every day, so it is not a document assembled the week before the audit.
Where to start this quarter
- Get the inventory. Put the sensor on the developer machines and let Article 26 have its list.
- Read the Article 14 findings first. Standing permissions are the fastest fix with the largest effect, and the story a regulator will understand.
- Hold new MCP servers and skills for review, so Article 15 stops getting worse while you work on it.
- Assign the three manual articles to someone by name and have them attest this quarter.
- Run the report at the end of the quarter and keep it. The obligations apply from August 2026, and the first audit will ask for a period of evidence, not a snapshot.
EU AI Act compliance for AI coding agents is not a new programme. It is the inventory, the permissions, the logs and the monitoring a security team would want anyway, with article numbers attached.
Frequently asked questions
Does the EU AI Act apply to a company that only uses AI coding agents? Yes, as a deployer. The Act puts obligations on providers, who build AI systems, and on deployers, who use them under their own authority. A company whose developers run Claude Code, Cursor or Codex on company machines is a deployer of those systems, and Article 26 sets out what it owes: use the system as instructed, keep a person able to oversee it, monitor its operation, keep the logs it produces, and report serious incidents.
Are AI coding agents high-risk under the EU AI Act? Not by category. The high-risk list in Annex III covers areas such as employment, credit and critical infrastructure, and a coding agent is not on it. What makes the Act matter is where the agent runs: with a developer's access to source, credentials and production systems. Most companies treat the agent estate under the high-risk obligations because that is the standard an auditor, a customer or a regulator will measure against after an incident.
What evidence does an auditor want for the EU AI Act and AI agents? A dated inventory of every agent on every machine, the risks found and what was done about them (Article 9), records of what the agents did (Article 12), proof that a person can and does intervene, including which agents hold standing permissions (Article 14), evidence of protection against prompt injection and malicious components (Article 15), and a monitoring log with incidents flagged (Articles 72 and 73). The parts that need a person, such as AI literacy under Article 4, are attested by name.
When do the EU AI Act obligations for deployers start? The general-purpose AI and governance provisions took effect on 2 August 2025. The high-risk obligations, including the deployer duties in Article 26 and the requirements in Articles 9 to 15 that they lean on, apply from 2 August 2026 for most systems, with a later date for high-risk systems embedded in regulated products. A company that started collecting evidence today would have its first full quarter of records before its first audit.