The sovereignty theatre
A DACH mid-market firm moves its LLM workload to a Frankfurt data centre, ticks the sovereign cloud box, and assumes it has addressed AI risk. Meanwhile, the customer service agent it deployed last quarter still holds standing write access to the CRM, read access to the ERP, and the ability to trigger approval workflows in the ticketing system. No expiration policy. No scope review. No audit trail linking actions back to the task that justified the access in the first place.
The sovereignty conversation—where the compute happens, which jurisdiction governs the data, whether the hyperscaler is US-owned—matters. But it addresses a narrow slice of enterprise AI risk. The larger, more immediate governance failure sits one layer down: non-human identities that act autonomously, inherit permissions designed for humans, and operate outside the lifecycle controls that IT teams spent a decade building for employees and service accounts.
A compromised agent, an over-permissioned agent, or an agent that drifts from its original task scope will do its damage regardless of whether the inference runs in a German data centre or a US region. The risk is not in the model weights or the hosting geography. The risk is in what the agent is allowed to do—and how poorly most organisations govern that question.
What makes agent identities different
Service accounts have been a governance headache for years. They proliferate, they rarely expire, and they often hold more permissions than any individual human would be granted. But they are at least static. A service account for a nightly ETL job does the same thing every night. Its behaviour is predictable. Its scope is narrow.
AI agents break that model. An agent designed to resolve support tickets might follow a dynamic sequence—reading ticket metadata, conditionally pulling customer records based on ticket type, querying relevant systems—with permission needs varying by execution path. The sequence is dynamic. The data touched is context-dependent. The permissions required vary by task. And because the agent is autonomous, it makes those decisions without a human in the loop.
This creates a governance surface that traditional identity and access management systems were never built to handle. Most IAM platforms can assign a role, enforce multi-factor authentication, and log access events. They struggle to answer: Did this agent need this specific permission for this specific task at this specific moment? And they have no mechanism to revoke access once the task is complete.
The result, in every production environment I have reviewed, is the same: agents are over-permissioned by default. Developers grant broad access during the pilot phase, the agent moves to production with those permissions intact, and no one revisits the scope until something breaks—or until a regulator asks why an agent designed to summarise documents also has write access to financial systems.
The runtime signals that matter
If you cannot prevent over-permissioning at design time—and most organisations cannot, because agent behaviour is emergent and task-specific—you need runtime detection. That means logging and analysing what agents actually do, not just what they are allowed to do.
Credential and secret access outside task scope is the first signal. If an agent fixing a rendering bug in a web application suddenly touches AWS credentials, that is not a legitimate escalation—it is either a compromise or a failure in task scoping. Least-privilege architecture is the defence here, but monitoring for out-of-scope credential access is the detection layer that catches when that architecture fails.
Permission usage patterns over time are the second signal. An agent granted ten permissions during development might only use two in production. That gap—between granted and exercised permissions—is a governance finding. It tells you the agent is over-provisioned, and it gives you a concrete list of permissions to revoke. In practice, analysing an agent's runtime behaviour over thirty days typically reveals that it used only one of the tools and two of the permissions it was initially granted. That is not a theoretical exercise; it is a direct input to access review.
Behavioural drift is the third signal. An agent that starts performing actions outside its documented purpose—querying datasets it was never scoped to touch, triggering workflows it was never designed to invoke—may be responding to adversarial prompts, may have inherited permissions from a compromised identity, or may simply be behaving in ways the developer never anticipated. Without persistent visibility into what the agent is doing, you cannot govern access, detect misuse, or demonstrate compliance.
The lifecycle gap
Most enterprises have lifecycle policies for employees: onboarding, access reviews, offboarding. Some have lifecycle policies for service accounts, though enforcement is often weak. Almost none have lifecycle policies for AI agents.
That means agents are born—spun up by a developer, granted permissions, pointed at production systems—without being registered into a governed inventory. They live without expiration policies, without ownership records, without reauthorisation triggers. And they die (or rather, they stop being used) without deprovisioning, leaving credentials active and permissions intact long after the agent's purpose has expired.
A mature governance model treats AI agents as first-class identities with enforceable lifecycle states. That includes discovering agents across cloud, SaaS, and scripting environments; registering them into an inventory with ownership and purpose metadata; assigning expiration, review, and reauthorisation policies; and enforcing deprovisioning as a default state. Without this structure, security teams are managing an undocumented parallel workforce—one that scales faster, operates more autonomously, and holds more permissions than the human workforce ever did.
The alternative is what I see in most DACH mid-market environments today: agents that exist in a governance shadow. IT knows they are running. Security knows they hold credentials. But no one knows how many there are, who owns them, what they are allowed to do, or when they should be decommissioned. That is not a sovereign cloud problem. That is an identity governance problem, and it will follow you to any hosting jurisdiction.
What regulators will ask
NIS2, DORA, and the EU AI Act all create obligations that touch agent governance, even if they do not name agents explicitly. NIS2 requires that entities maintain an inventory of assets, implement access controls, and ensure accountability for actions taken by automated systems. An agent that can modify production data, trigger financial transactions, or access customer records is an asset. If you cannot inventory it, control its access, or trace its actions, you are not compliant.
DORA requires financial entities to manage ICT risk, including third-party and operational dependencies. An AI agent is an operational dependency. If it fails, if it is compromised, or if it behaves unpredictably, the impact is operational. The risk management framework must account for that, and the testing regime must validate that controls work under stress. You cannot test what you have not inventoried, and you cannot manage what you have not scoped.
The EU AI Act, particularly for high-risk systems, requires human oversight, transparency, and the ability to intervene. An agent that operates autonomously, without runtime monitoring, without task-level audit trails, and without a mechanism to revoke permissions mid-task, fails the oversight requirement. Sovereignty does not fix that. A governed identity lifecycle does.
The engineering work that matters
Fixing this is not a procurement exercise. It is an engineering and governance exercise, and it requires three capabilities that most mid-market DACH firms do not yet have in place.
First, visibility. You need an inventory of every agent, every identity it uses, every permission it holds, and every system it touches. That inventory must be live—updated as agents are created, modified, and decommissioned—and it must be queryable, so that security and compliance teams can answer questions like "which agents can write to the ERP?" or "which agents have not been reviewed in the last ninety days?"
Second, fine-grained access controls. Agents should not inherit role-based access designed for humans. They need task-scoped, time-bound permissions that map to the specific actions they are designed to perform. That means moving beyond "this agent is a service account with contributor access" to "this agent can read customer records in the CRM, but only for tickets assigned to it, and only for the duration of the task."
Third, lifecycle enforcement. Every agent needs an owner, an expiration date, and a reauthorisation policy. When the agent is no longer needed, its credentials must be revoked and its permissions must be deprovisioned. That sounds obvious, but it is not the default in any environment I have reviewed. The default is that agents live forever, and their permissions accumulate.
None of this is solved by choosing a sovereign cloud provider. It is solved by treating agents as a new category of identity, with governance requirements that are stricter than those for humans and more dynamic than those for traditional service accounts. The firms that figure this out early will have a structural advantage when regulators start auditing AI risk. The firms that assume sovereignty is sufficient will discover, too late, that the risk was never in the hosting location—it was in the permissions.
A Diagnostic maps your current agent inventory, identifies over-permissioned identities, and defines the lifecycle controls you need before a regulator asks—or before an agent acts outside its scope.