Your AI Coding Bots Are Running Unsupervised and Nobody Knows What They Did Last Night
AI agents inside software development teams can write, test, and deploy code on their own, often with no human checking what they did. Most companies have no way to answer a simple question: who authorised that change?
Key points
- The average organisation now runs 22 separate AI agent projects, according to recent industry research, spanning departments from legal to engineering.
- AI agents in software teams can write code, open change requests, and push updates to live systems, sometimes with no human reviewing a single step.
- Unlike a normal automated account, an AI agent sets its own path to reach a goal, making its behaviour fundamentally harder to predict or audit.
- Most companies cannot tell regulators or auditors which AI agent introduced a specific piece of code, or whether any human was involved.
- The compliance rules under the Sarbanes-Oxley Act, a US law requiring companies to prove financial and technical controls, have existed for over 20 years, but AI agents are making those controls nearly impossible to demonstrate.
There is a quiet crisis unfolding inside engineering teams right now, and it does not show up in breach headlines. It shows up in postmortems, audit findings, and the 2 a.m. Slack messages asking who approved that deployment.
The problem is AI agents.
Not the helpful kind that suggests a line of code while a developer types. The other kind: fully autonomous software programs that receive a goal, figure out the steps themselves, write the code, run the tests, and push the result to production, all while your security team is asleep and your audit log shows nothing useful.
How did these agents end up with so much access?
They got it the same way every other automated tool does: a developer needed something done quickly, created an account or access key for the agent, and moved on. Nobody deprovisioned it. Nobody checked what it touched next week, or the week after.
That is the failure mode here. It is not dramatic. It is just the ordinary accumulation of ungoverned access, except the thing holding that access can now make decisions independently, at machine speed, across an entire codebase.
A normal automated account, what engineers call a service account or an API token (a kind of digital pass that lets software talk to other software), does exactly what it is told. Nothing more. An AI agent is different. It is handed a target and works out the route itself. That distinction sounds abstract until you realise it means no human defined the specific actions the agent would take, which means no one can easily reconstruct them afterward.
Dark Reading recently covered analysis from identity security researchers who put the problem plainly: governance models built for human developers assumed human speed and human judgment. Models built for automated tools assumed predictable, bounded behaviour. AI agents break both assumptions at once.
The coding-assistant phase, tools like GitHub Copilot or Cursor that suggest code while a person makes the final call, is one risk level. Most security teams are at least beginning to think about it. Fully autonomous agents are a different category entirely, and that category is arriving faster than most governance teams are ready for.
In practice, the organisations that are furthest behind are not the ones ignoring AI. They are the ones who enthusiastically adopted it, let developers spin up agent projects on personal accounts, and never built the inventory to know what exists.
The question auditors and regulators will eventually ask is simple: if an AI agent introduced a vulnerability or made an unauthorised change, can you show exactly what happened, which identity did it, and whether a human approved it? For most organisations today, the honest answer is no.
Four things help close that gap. Know every agent running in your environment, including the unofficial ones. Know what each agent can access and what it has actually used. Build a baseline for normal behaviour so abnormal behaviour stands out. And when a project ends, revoke the access that came with it.
None of that is exotic. It is standard practice for managing human accounts. The frameworks just have not caught up to apply it to AI agents yet.
The window to get ahead of this is open. It will not stay open indefinitely.
Operational takeaway: if you cannot pull a report today showing every AI agent with write access to your CI/CD pipeline (the automated system that builds and ships software), that report is your first priority next sprint.
