On 17 October it will be two years since EU member states were due to transpose the NIS2 Directive into national law. Several still haven't. On 6 October, France's National Assembly pulled the Résilience bill, which transposes NIS2, from its 7 and 9 October agenda. The rapporteur said he hopes to reschedule it "within fifteen days or three weeks" (Leto). Spain's draft Ley de Coordinación y Gobernanza de la Ciberseguridad had still not appeared in the BOE as of August. On 8 July the European Commission referred Spain, together with Ireland, France and the Netherlands, to the Court of Justice and asked for a lump sum plus daily penalties (NIS Solutions).
It is tempting to read the delay as breathing room. That would be a mistake, and AI coding agents are the clearest example of why. The directive's risk-management measures are already written down. National laws will add authorities, fines and scoping details, but they won't change much about what "appropriate and proportionate" looks like for software that runs shell commands with a developer's credentials.
What NIS2 actually asks for
Article 21 requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures" to manage risks to the network and information systems they use. Article 21(2) then lists a minimum set of measures (Art. 21 text). Four of them land directly on AI coding agents:
- (d) Supply chain security. Agents install packages, register MCP servers and load plugins and skills, often from sources nobody reviewed.
- (e) Security in development and maintenance. The agent is now a participant in your development process, writing code, changing configuration and running builds.
- (f) Assessing whether controls work. You can't assess what you can't observe. If you don't know what your agents did last week, you can't show your measures are effective.
- (i) Access control policies and asset management. An agent acting under a developer's session inherits that developer's access unless something narrows it.
Article 20 puts this on the board. Management bodies must "approve the cybersecurity risk-management measures", "oversee its implementation" and "can be held liable" for infringements (Art. 20 text). Article 23 adds the clock for significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report covering likely root cause within one month (Art. 23 text).
Why agents strain controls you already have
Most organisations already have access control, change management and logging. Coding agents fall between them. Identity systems see a developer's session, not an agent acting inside it. EDR sees a developer's terminal spawning processes, which is what developers do all day. Change management sees the commit, not the 40 commands that ran before it. And the agent's own guardrails, the permission prompts and approval modes, usually live in configuration on the same machine the agent runs on.
That last point became a concrete vulnerability this year. Cymulate's research team found that Claude Code, Cursor, Codex CLI and Gemini CLI on Windows all trusted machine-wide configuration under C:ProgramData, a location where a standard user can create folders and write files. A low-privileged user could plant a config file with hooks that ran in the context of whichever user launched the tool next, administrators included. For Codex CLI, the same file could also set sandbox_mode = "danger-full-access" and approval_policy = "never". Anthropic moved its managed settings to a write-protected location and assigned CVE-2026-35603. When Cymulate published, it said fixes for the other three tools had not been confirmed (Cymulate).
The lesson is bigger than one CVE. If the policy that decides what an agent may do is a file that a local user or process can edit, it isn't an access control policy in the Article 21(2)(i) sense. It's a preference. The same goes for logs the agent can reach: a record the actor can rewrite is weak evidence when you are filling in a 72-hour notification.
The pattern that holds up
You don't need a new framework. Apply the controls you already use for privileged humans to agents, and enforce them somewhere the agent can't reach:
- Least privilege by default. Unknown actions shouldn't silently succeed. Explicitly allow the routine work (tests, builds, reads inside the repo), and route everything else to a human.
- Allow, ask, deny at the action layer. Judge the command, file write or network call, not the prompt text. Deny reads of credential files and calls to cloud metadata endpoints. Ask before new package sources, pushes to unapproved remotes or anything touching production.
- Policy owned centrally, not on the laptop. The organisation sets the floor; departments and teams can tighten it. A developer, a repository or a planted config file shouldn't be able to loosen it.
- Supply chain gates. Treat installing a package, registering an MCP server or adding a plugin as running third-party code, because that is what it is. Ask by default, allowlist what has been reviewed.
- Evidence outside the agent. Log every attempted action with its verdict, user, device and timestamp, in a store the agent can't modify, and export it to your SIEM. That record is what turns a 24-hour early warning from a guess into a statement.
Mapping it to the directive
Once the pattern is in place, the compliance mapping is short. Central allow/ask/deny policy with least-privilege defaults is your Article 21(2)(i) access control for non-human actors. Ask-by-default on installs and new tool registrations is a practical answer to (d). An external, immutable audit trail is what (f) effectiveness assessment and Article 23 reporting rely on. Board-approved policy, versioned and changed through a reviewed process, is how Article 20 oversight becomes something you can show rather than assert.
This is the layer DarkControl provides. A lightweight endpoint agent checks every shell command, file write and network call made by Claude Code, Codex, Cursor, Copilot and other coding agents against central policy. It returns allow, ask or deny, defaults unmatched actions to ask, and writes each attempt to an immutable log with SIEM export. Compliance views map the results to NIS2, the EU AI Act, ISO 27001 and SOC 2.
What to do before your national law lands
- Inventory. List which coding agents run on which endpoints, under which accounts. Asset management under (i) covers them.
- Baseline. Watch agent activity for a week without blocking anything. Real data on what agents touch beats a policy written from guesses.
- Write the floor. Set three to five deny rules everyone agrees on: credential files, metadata endpoints, force-pushes to protected branches, public repo creation. Default everything else unknown to ask.
- Lock the policy location. Make sure agent guardrails can't be changed by a local user, a repository file or another process, and alert when someone tries.
- Rehearse the clock. Pick a past week and see whether you could reconstruct what one agent did in under 24 hours. If not, that's your first gap.
- Take it to the board. Article 20 makes agent governance a management decision. Present it as one.
If you want to see what your agents are doing before deciding what to block, DarkControl offers a free 7-day watch-only audit on up to 10 devices. Nothing is blocked; you just get the record.
