The Lifecycle That Was Never There

The framing of shadow AI as a data protection problem is intuitive and almost entirely wrong.

The intuitive version: an employee connects a personal AI assistant to their work email, the assistant processes confidential client communications, the data leaves the organisational perimeter. Article 33 breach. Notification obligation. Supervisory authority investigation. The failure is located in data classification, perimeter control, acceptable use policy. Fix those and you have addressed the risk.

This is the wrong level of the problem. It addresses what travels while ignoring what persists.

The more accurate framing is access control. An employee who connects an AI assistant to their work systems does not merely create a momentary data transfer. They create a credentialled relationship between an external system and internal organisational resources. The credentials exist. They are valid. They persist beyond the session that created them, beyond the task that motivated them, and in most enterprise environments, beyond the employee who established them.

The data is not the issue. The data was already there. What changed is that something outside the organisation now has a key.

This is the moment access is granted. Hold it in mind, because there is a matching moment at the other end of the story — the moment access should have been taken away and never was — and the two moments turn out to be the same problem, photographed from opposite directions.

The way in

Enterprise AI adoption has created a new category of access event that existing identity and access management frameworks were not designed to track. When a human employee is granted access to a system, that grant is logged, attributed to an individual, and tied to an employment relationship that has a beginning and an end. When that employment ends, access is revoked - not always promptly, not always completely, but within a framework that at least acknowledges revocation as a required step.

When an AI assistant is connected to work systems by an individual employee, the access grant is typically not logged centrally, is not attributed to the organisation in any formal sense, is not tied to any employment relationship, and has no revocation trigger. The assistant does not have an employment contract. It does not have an offboarding process. It does not appear in the identity management system as an entity with access. It simply has access, because someone gave it access, and no mechanism exists to notice that access was given or to determine when access should end.

The scale is not hypothetical. Enterprise surveys in 2026 put unsanctioned AI use at around 98% of organisations, and roughly 79% report no visibility into the AI agents and connected systems operating inside their own environments. That is not a margin of shadow activity around a governed core. It is the condition.

You cannot revoke access you do not know exists. You cannot audit a data relationship you cannot see. You cannot fulfil data subject rights under Chapter III of GDPR for processing you cannot investigate, because the processor - the AI assistant - was never registered as a processor, and the controller - the organisation - has no record that processing occurred.

The way out

Now run the same failure forward in time.

Consider an agent deployed eighteen months ago to automate a procurement workflow. The workflow changed. The project ended. The team moved on. No one thought to revoke the agent's credentials, because revoking credentials requires knowing which credentials exist, and knowing which credentials exist requires someone to have maintained a record, and maintaining a record requires someone to have decided, at the point of deployment, that this was necessary.

No one decided that.

The agent is still there. It still has read access to the vendor database, write access to the procurement system, and an API token to the financial reporting tool that was connected in week three because someone thought it might be useful. It has not done anything wrong. It is waiting. It will continue to wait indefinitely, with full credentials, in an environment it was never formally told to leave.

This is what security researchers in June 2026 named the orphaned agent: deployed, forgotten, never deprovisioned - a systematic hidden access risk sitting inside organisational networks, holding live credentials to systems their nominal owners have ceased to think about. One measurement gives the shape of it: in one large sample of agentic chatbots, some 65.4% had never been used after creation, while their credentials remained active. Dormant authority is still authority.

So the two stories meet. Shadow AI is access no one authorised on the way in. The orphaned agent is access no one revoked on the way out. They are not two problems. They are a single missing lifecycle, visible from both ends - an entrance with no log and an exit with no condition.

The AI Agent Has Your Keys identified the identity problem: agents hold OAuth tokens and API keys that outlast the decision to grant them, because the mechanisms for revoking access are separate from the mechanisms for granting it and nobody connects the two. The Principal Who Wasn't There identified the authority problem: agents act on behalf of principals whose actual authority to delegate was never defined. The missing lifecycle is what happens when both compound over time. The key was never in scope, and it was never returned.

What the open exit costs

For most of the orphaned agent's life, nothing happens. It waits. The danger is that an agent with persistent access, live credentials, and real authority over real resources is precisely the thing worth hijacking - and that an agent no one is watching is precisely the thing no one will notice being hijacked.

In June 2026, Microsoft researchers demonstrated how. The exploit, called AutoJack, was shown against AutoGen Studio - Microsoft Research's prototyping interface for multi-agent systems - and it chained three weaknesses to let a single malicious web page cross the localhost trust boundary and execute code on the host running the agent. A browsing agent rendering the page inherits the local machine's identity; attacker-controlled instructions on the page then satisfy checks that were meant to keep outsiders out. In proof-of-concept testing, a calculator launched on the developer's desktop seconds after the agent loaded the page - started not by the browser, but by the agent process itself.

Two caveats matter, and neither weakens the point. First, AutoJack as demonstrated was specific: it targeted AutoGen Studio, and Microsoft states the vulnerable code lived only in development builds with experimental tooling and was never shipped through the public release. This was a proof of concept, not a worm in the wild. Second - and this is the part that survives the patch - the agent did not malfunction. It did exactly what it is designed to do: read instructions and follow them. From the agent's perspective, the instructions were instructions.

That is why the specific bug is almost beside the point. What AutoJack requires, to turn a clever demo into a breach, is an agent that has something worth hijacking - persistent access, stored credentials, standing authority - and that no one is watching. The orphaned agent is the definition of that target. The exploit and the orphan were published within days of each other, and they are halves of one sentence: here is an agent no one remembers, and here is how little it takes to make it act.

Who is the controller?

The legal question this produces is worth stating precisely, because it is not the one most incident-response frameworks are built to answer. GDPR assigns controller status to the entity that determines the purposes and means of processing. The missing lifecycle breaks that assignment at both ends.

At the entrance: a specific employee has made a unilateral decision that the organisation's data should be reachable by an external AI system. The organisation did not determine the purposes - the employee did. It did not determine the means - the employee chose the assistant, the connection, the scope. It does not know the processing is occurring. If the employee was not acting with organisational authority - and shadow AI, by definition, means they were not - the controller question is genuinely open. The organisation does not control the processing; the employee is not a legal person capable of being a controller; the provider supplies the technical means but did not decide to connect to this particular data.

At the exit: an orphaned agent is hijacked and used to exfiltrate personal data from systems it was originally credentialled to reach. At the moment of the breach, purposes and means are being determined by the attacker, through an agent the original deployer nominally controls but has in practice abandoned. The attacker has no legal relationship to the data. The deployer is determining nothing. Authority is being exercised by a party with no standing, using a delegation by a party who no longer knows they made it.

Neither of these is a drafting flaw in GDPR. The Regulation assumed the entity responsible for processing would know it was responsible, would have made a deliberate decision to process, and would be capable of the meaningful control that controller status implies. An organisation that has forgotten an agent exists — or never knew an employee connected one - cannot exercise meaningful control over anything that agent does.

And the obvious defence does not survive contact with the text. When the supervisory authority asks the controller to explain the breach and the answer is we did not know the agent still existed, that is not a mitigating circumstance. Article 5(2) makes the controller accountable for compliance; the accountability principle exists precisely so that responsibility cannot be disclaimed on the basis of one's own inattention. The failure to maintain a registry of active agents, to expire credentials, to review access - that is not the context of the breach. It is the breach. The data loss is merely the moment it became visible.

But accountability has to be exercisable to be demanded. A controller with no visibility into the agents operating under its authority cannot implement the technical and organisational measures Article 32 requires, cannot satisfy Chapter III rights for incidents it cannot investigate, cannot do the thing the law is holding it responsible for not doing. The Regulation requires accountability. The deployment practice produces agents that are structurally unaccountable. Something has to give, and it will give first in enforcement.

The Clause is fond of agents like these - credentialled, unrecorded, answerable to no one who remembers issuing the credential. They are the nearest thing in software to a rule that binds everyone and names no one.

The lifecycle, built

The remedy is not exotic, which is the quietly damning part. The Agent Did It argued that agents competent enough to write their own post-mortems should be required to conduct their own pre-mortems. The same logic applies across the whole lifespan: an agent deployment that has neither a controlled entrance nor a defined exit is not a completed design. It is a deployed fragment.

The controls are identity-centric, not perimeter-centric, because the problem is access, not leakage. Applying data-loss tooling to an access problem leaves you watching the water while staying blind to who was handed the tap. What is needed instead is a way to detect when external systems connect to internal resources; a registry that records every deployed agent, its credentials, its scope, and its nominal owner; credentials that expire and require active renewal; periodic access reviews that surface agents whose owners have left or whose workflows have ended; and a revocation pathway that does not depend on the original employee being available to walk it.

None of this is novel engineering. Enterprise identity systems can already do all of it. The enterprise MCP authorization work published in June 2026 is one attempt to build the recognition into infrastructure - managed, auditable, revocable grants for agents operating inside organisational boundaries. Its existence is encouraging. Its adoption is a separate question, and the problem predates it by the length of time AI assistants have been consumer products.

What is missing is not capability but a single act of recognition: that an AI agent is an access subject - an entity that has been let into protected resources and that needs the same lifecycle as any other thing you let in. A beginning that is logged. An end that is enforced.

You cannot revoke access you do not know exists. You cannot be accountable for processing you have no record of. The orphaned agent was never given an exit condition because no one thought about the end of the deployment while thinking about the beginning - and the shadow agent was never given an entrance condition because no one was asked at all.

The key is under the mat at both doors. The problem was never only that someone might take something on the way out.

The problem is that no one was watching either door, and the mat is still there.