The incident report calls it the first known case of an “automated agent collective acting offensively without authorization.”That sounds like a persistent AI collective launching a coordinated attack.

But technically, something different happened.

OpenAI had agents work on cybersecurity tasks in separate runs and isolated containers. One run started and ended. A later run was a new execution.

But some of these separate runs could access the same infrastructure.

That included Artifactory, an internal package server. Agents began leaving messages there. Other runs found them. The package server became an improvised message board where commands, results, tools, and credentials were later made available.

The runs were separate. What they left behind was not.

This eventually became a chain of actions.

One run found 14 Hugging Face credentials in a publicly accessible dataset and left them for later runs. Other runs found vulnerabilities and obtained production credentials. Those credentials and other results were shared as well. Later workloads could build on them.

It was not one powerful agent breaking through a boundary.

Multiple boundaries proved permeable in sequence, and the result of one step could become the starting condition for the next.

That is where the governance problem begins.

Capabilities, resources, access, and isolation can be constrained for an individual workflow.

But the chain of actions could extend beyond the boundary of that individual workflow.

Workflow
→ action
→ persistent result
→ shared, accessible infrastructure
→ another workflow
→ further action.

The first workflow may have ended long ago. Its result can still continue to matter in a later action.

This creates a divergence between two boundaries:

the boundary of the governance unit and the possible reach of the operational action chain.

The individual workflow remains an object of governance. But governance that considers only that unit can miss the transitions through which its action results continue to have effects in other workflows.

This makes the operational embedding of workflows and the transitions between them governance-relevant as well.

The open question is no longer whether the workflow boundary alone limits that operational reach. It is how far governance must follow a chain of actions that extends beyond that boundary.

No more than €350.
On a specific day and within a specific time window.
No more than one stop.
A window seat.
The agent has four days.

At this point, there is no specific financial action yet.

You have given the agent a bounded mandate.

Within this mandate, the agent can search, compare offers, and later make a specific selection on its own. The flight it eventually books may not even exist at the time you give the instruction.

Only later does the agent turn that mandate into a concrete action:

Book this flight for €345.

And this is where the authorization question changes.

The resulting payment can then enter the existing authorization and processing infrastructure.

But before that, an autonomous agent introduces a different question that must be answerable:

Why is this agent allowed to make this specific booking?

Is the price within the mandate?
Do the date and time window match?
Does the itinerary have no more than one stop?
Does the booking meet the seat requirement?
Is the mandate still valid?

The payment itself does not contain these answers.

The agent has turned a delegated mandate into a concrete financial action. This introduces an authorization question before the payment transaction itself: whether the specific agent action is still covered by the delegated mandate.

Delegated mandate → Agent → Concrete action → Mandate check → Payment transaction → Payment authorization

That is the structural change:

In agentic payments, the payment transaction is no longer the starting point for authorization.

But the agent’s identity does not yet determine the authority under which it acts.

Google distinguishes between an agent acting on its own authority and an agent acting with authority delegated by a user. The agent can therefore remain the same identifiable principal while the authority context behind a specific action changes.

This means that three questions need to be kept separate:

Who is acting?

On whose authority is it acting?

What is it authorized to do?

Cryptographic identity makes the agent identifiable. Its status as a principal makes the agent an identifiable subject of authorization. For authorization, this means that alongside the identified principal, the authority context under which the action takes place also becomes relevant.

The structure is therefore not simply:

Identity → Permission.

Rather:

Agent Identity → Principal

+ Authority Context → own or delegated

→ Authorization → authorized scope of action

This distinction becomes particularly relevant for reconstruction. If the same agent can act under different authority contexts, knowing which agent performed an action is not sufficient to reconstruct the governance conditions under which that action took place.

This distinction also becomes relevant for audit reconstruction: the Google architecture can keep agent identity and, in cases of delegation, user identity separately visible.

But even this does not fully represent the authority context. The identity of the delegating user shows to whom a delegation can be attributed. By itself, it does not determine what authority actually applied to the specific action.

Stable identity does not imply stable authority.

This does not, however, resolve the authority problem.

A verifiable agent identity and an attributable delegation do not by themselves determine how long delegated authority remains valid, how tightly it is bound to a specific action, or what happens if that authority changes between authorization and execution.

These are separate control conditions.

The governance question therefore extends beyond identifying the executing agent:

If the same agent can act under different authority contexts, what must remain reconstructable about the authority behind each individual action?

Reference:

Google Cloud, Agent Identity Overview

In a post, Raghvender Arni (Google) describes an agentic enterprise scenario in which this interaction does not rely on a single standard. Different functions are addressed separately: Open Knowledge Format (OKF) structures internal purchasing rules, Agentic Resource Discovery (ARD) is used to discover resources and endpoints, Agent2Agent (A2A) structures the interaction between agents, and SPIFFE provides cryptographically verifiable runtime identity.

What is notable is what this architecture does not require.

A2A explicitly treats the internal execution of the remote agent as opaque. The client does not need to know its internal state, memory, or the tools it uses for the two agents to interact.

The response to this opacity in the Google corpus examined here is not full transparency. Instead, specific conditions of the interaction are made explicit.

Policy context can be represented in structured form. Resources can be described and discovered. Interactions and task states can be formalized. Runtime identities can be made cryptographically verifiable.

The agent as a whole does not become transparent. Specific conditions of its interaction become explicit.

This changes the object of control.

Control does not have to depend entirely on being able to inspect the internal decision logic of another agent. Specific control conditions can be explicitly represented or made addressable or verifiable outside that logic.

This is not, however, a complete governance solution.

A verifiable identity does not prove correct execution. Structured policy context does not prove that a policy has been applied correctly. Discovery does not prove that a discovered resource is permitted for use. And a formally described task does not make the executing agent’s internal decision logic transparent.

This brings a more precise governance question into view.

Not only:

How transparent is the agent?

But:

Which conditions of a specific interaction must be explicit, verifiable, and reconstructable for control to remain possible under opaque execution?

This connects to our analysis „The Carrier Stability Problem“: governance does not operate directly on risks, but through carriers on which its functions can be exercised. The Google corpus examined here shows more concretely how, under agentic conditions, different parts of an interaction can become explicitly addressable.

References:

Raghvender Arni (Google), Enterprise AI Agent Interoperability Workflow

AI Governance & Markets, The Carrier Stability Problem

But these controls rely on an assumption:

that the conditions they enforce still hold.

This is where a different governance problem emerges.

A system can behave correctly and a control can function correctly while the conditions underlying the original authorization have changed.

The deployment context can change. The system’s capabilities can shift. Responsibilities or workflows can change.

A technically robust control architecture can therefore provide precise evidence that a governance condition was enforced correctly even though that condition is no longer appropriate.

These are two different questions:

Enforcement correctness:
Was the specified condition enforced correctly?

Governance validity:
Does that condition still hold under current circumstances?

This is where runtime control reaches its limit. When an authorization is translated into an executable control, it must be possible to verify not only whether that control operates correctly, but also whether the conditions underlying the authorization still hold.

That assessment cannot simply be performed by the runtime control itself. Its task is to enforce the applicable condition. If it were also to decide whether that condition still holds or needs to be changed, enforcement, revalidation, and modification would be combined within the same authority.

A trigger for revalidation does not fully solve the problem either. It can only respond to changes that produce a relevant signal within its defined observation space. Other changes may fall outside that space. They may also become visible first in the surrounding workflow while runtime telemetry continues to appear normal.

The absence of a trigger therefore cannot automatically mean that an authorization remains valid.

Between two reviews, a condition may remain formally in force even though its underlying assumptions have already eroded.

The tolerable delay before revalidation therefore depends on the deployment context. The higher the execution frequency and the greater the potential consequences, the shorter the acceptable interval between reviews may become. This raises requirements for provider-side architecture, evidence capabilities, and integration.

Revalidation therefore becomes more than a governance requirement. It affects integration costs and the conditions under which a system can be deployed operationally.

The architectural question therefore shifts:

From:
Where and how is a governance condition enforced?

To:
How do we know when the conditions underlying an authorization no longer hold, when must they be revalidated, and who has the authority to change them?

Regardless of how individual political announcements are assessed, this development points to a broader structural shift.

International AI competition is expanding into an institutional dimension.

For years, competition centered on models, computing power, and semiconductors. These factors remain decisive. At the same time, countries are increasingly competing through the institutional offerings they build around AI.

The United States emphasizes technological leadership and an innovation-driven ecosystem.

The European Union emphasizes regulatory reliability, trust, and institutional governance.

China increasingly positions itself through infrastructure, international engagement, and capacity building.

These approaches differ in their design. Yet they follow the same strategic logic: to create an institutional offering that other countries, companies, and organizations choose to join voluntarily.

Institutional attractiveness creates voluntary participation. Voluntary participation creates shared standards, governance structures, and organizational ties. Those ties, in turn, create long-term opportunities for influence.

Governance is therefore becoming a geopolitical value proposition. Geopolitical influence no longer begins only with the projection of power. It begins with institutional attractiveness.

Yet a different structural movement is becoming increasingly visible.

Governance is shifting its object.

No longer only:

• Which action is permitted?

• Which decision may be executed?

Increasingly, it is about:

• Access to frontier capabilities (EU Frontier AI Expert Report)

• Generation of context-specific policies (Google Semantic Governance)

• Evidence as the basis for decisions

• Context as a prerequisite for decision-making

Governance is moving further upstream in the decision process. It no longer regulates decisions alone.

It increasingly regulates the conditions under which decisions are formed.

This changes more than the location of governance.

It changes its object.

The immediate explanation was political.

The more interesting finding is structural.

The case revealed that the critical dependency was not where many AI sovereignty debates assume it is. Much of the discussion focuses on data centers, cloud infrastructure, or local deployment. The intervention happened elsewhere.

As a result, the question of control changes as well. An organization can operate infrastructure, integrate workflows, and build processes around a capability without actually controlling the continuation of that capability.

At first glance, the case looks like a political exception. In reality, it exposes a structural bottleneck.

The critical resource is not the infrastructure.

The critical resource is access.

Whoever controls access increasingly controls the continuation of the capability.

By 2035, the market share of European cloud and AI computing providers in the European market is expected to reach 30%. This is the stated objective of the Cloud and AI Development Act (CADA).

It sounds like the result of an analysis or a forecast.

It is not.

In the impact assessment, the 30% figure appears as a target. The document then examines which growth rates would be required to reach that outcome.

The impact assessment itself makes this point. The CAGR assumptions do not constitute a forecast. They were chosen to broadly match the desired outcome. (Impact Assessment Annexes (SWD(2026) 503), Annex 4, Section 8)

The analysis does not generate the target.

The target generates the analysis.

This shifts the real question.

Not:

Will Europe reach a 30% market share?

But:

Under which conditions could 30% become conceivable in the first place?

The impact assessment describes in considerable detail the conditions under which 30% could become conceivable. It points to demand aggregation, public procurement, sovereignty requirements, lower switching costs and specific support measures. (Impact Assessment Annexes (SWD(2026) 503), Annex 4, Section 8)

What remains unanswered is how those conditions are actually supposed to be created.

That is where it becomes clear whether a target merely appears plausible or is actually achievable.

This is precisely what exercised oversight looks like.

The RSB did not challenge the political objective of the initiative.

It challenged the justification.

The measures were considered insufficiently specified. Their proportionality had not been sufficiently demonstrated. The causal links between measures and expected effects were not sufficiently substantiated. The economic reasoning and the cost-benefit assessments were also considered insufficiently convincing. (Impact Assessment (SWD(2026) 502), Annex 1.3, Table 2)

This is the crucial point.

The RSB did not say:

The objective is wrong.

It said:

The homework has not been done.

And without that homework, there was no positive opinion.

In many procedures, criticism has little practical consequence. It is registered, answered, or simply acknowledged.

In the CADA process, that was not enough.

The criticism had to be addressed.

The Commission’s response shows that the criticism was procedurally consequential. The impact assessment was revised. Measures were specified in greater detail, the intervention logic was expanded, and parts of the economic reasoning were strengthened. (Impact Assessment (SWD(2026) 502), Annex 1.3, Table 2)

The specific changes matter.

More important, however, is the fact that they had to be made.

That is precisely what distinguishes symbolic oversight from exercised oversight.

Symbolic oversight expresses criticism.

Exercised oversight compels rework.

The Commission did not receive a positive opinion before that rework had taken place.

The first part examined the tension between infrastructure and dependence.

The second part examined the diagnosis of a demand and coordination problem.

This leaves one final question. If the proposed measures are actually implemented, how would the Commission later determine whether they are working?

Reading the monitoring and evaluation section, one notices how systematically this question is intended to be answered.

The impact assessment develops an extensive architecture of indicators, targets, and evaluations. Among other things, it monitors capacity expansion, market shares, provider presence, and dependencies (Annex 11).

At first, this is unsurprising. Anyone who formulates ambitious goals must also be able to determine whether those goals are being achieved.

The document becomes more interesting elsewhere. The further one follows the monitoring system, the clearer it becomes that the impact assessment distinguishes between two different levels.

On the one hand, it is concerned with the implementation of the measures themselves. On the other hand, it is concerned with the long-term effects those measures are intended to produce.

For implementation, the document provides early-warning mechanisms. Monitoring is intended to make potential bottlenecks or delays visible at an early stage and, where necessary, enable corrections during implementation (Annex 11).

For the actual outcome objectives, the architecture is structured differently. Provider shares, dependence reduction, or structural market changes are observed primarily through later evaluations, in some cases with multi-year time horizons (Annex 11).

At this point, a distinctive feature of the document begins to emerge. The impact assessment describes with considerable precision what progress would look like. Considerably less attention is given to the question of what happens if that progress fails to materialize.

For implementation problems, the document contains early-warning and correction mechanisms. For the actual outcome objectives, observation, evaluation, and later political decisions play a more prominent role.

As a result, the architecture becomes very strong in observing developments. The connection between observation and mandatory adjustment - through predefined or escalating response pathways in the event that targets are missed, for example - remains considerably more restrained.

This does not mean that failing to meet targets would be without consequences. The actual response to such developments remains more dependent on the later actions of the institutions involved.

The first part examined the tension between infrastructure and dependence.

This raises an obvious question: What is the actual problem from the Commission’s perspective?

Those who follow the public debate about Europe’s position in the cloud and AI market usually expect familiar answers at this point: too little capital, too little scale, too few European champions, too little computing capacity.

However, reading the impact assessment creates a different impression. What stands out first is where the document places its emphasis. The discussion revolves relatively little around the question of whether European providers are fundamentally capable of offering competitive services. Instead, the impact assessment repeatedly focuses on requirements, procurement, scaling, and market organization.

The further one follows the argument, the clearer a recurring pattern becomes.

Sovereignty requirements are formulated differently. Public procurement remains fragmented. Criteria are not comparable everywhere. Demand emerges in many places, but only to a limited extent becomes legible as a common market signal. Taken individually, these points appear almost administrative.

In the document, however, they become a market problem. This is because demand does not only fulfill an economic function. It also fulfills a coordination function.

When requirements are formulated differently across authorities, member states, and organizations, demand becomes difficult to compare. When demand becomes difficult to compare, it becomes difficult to pool. Without pooling, the long-term and sufficiently large contracts that are important for scaling emerge less frequently.

The impact assessment describes precisely this connection several times. According to the Commission’s presentation, the European market share stands at around 15% and shows no discernible tendency to change (Part 1, Section 2.4). At the same time, the document repeatedly points to fragmented demand, differing procurement logics, and the absence of common standards.

At this point, it becomes clear why the definition of sovereignty plays such a central role in the document.

At first glance, it appears to be a regulatory classification. Over the course of the impact assessment, however, it takes on another function.

The sovereignty tiers make requirements more comparable. This allows public institutions to describe their needs in more similar ways. Only then does the possibility emerge of bringing demand together across individual authorities or member states.

Why this matters becomes clear elsewhere. The impact assessment repeatedly points to the importance of larger and more stable contract volumes. Individual procurement procedures hardly change market structure. Coordinated demand, by contrast, can reach scales that become relevant for scaling.

The definition of sovereignty thereby acquires an additional meaning. It does not only serve to classify providers or services. At the same time, it creates the conditions under which demand can become visible as a common signal at all.

By the end of this argument, a remarkable picture emerges. The impact assessment describes a market in which requirements are difficult to compare, demand is difficult to pool, and scaling therefore becomes difficult to achieve.

This is precisely where the majority of the proposed measures intervene.

This also changes how CADA appears. The document no longer appears merely as an infrastructure package or a sovereignty package. It increasingly appears as an attempt to transform fragmented public demand into a coordinated signal of scale.

This also shifts the actual challenge. The central issue is not the existence of demand, but its organization.

The third part examines another distinctive feature of the document: CADA measures many of the decisive variables with surprising precision. The question is what happens when these targets are missed.

More infrastructure can be created without automatically reducing dependence on a small number of large providers.

This is where a tension begins that runs throughout the entire document. One of the central objectives of CADA is the expansion of digital infrastructure in Europe. The rationale is straightforward. Demand for cloud and AI computing capacity is growing, while large parts of the market remain concentrated among a small number of providers and locations.

At first glance, the logic appears simple. More infrastructure should strengthen Europe’s position.

However, reading the impact assessment produces a more differentiated picture. The document devotes considerable attention to the expected capacity gap. Permitting procedures, grid bottlenecks, and infrastructure constraints are described as key obstacles to further growth. The proposed response is correspondingly clear: accelerate permitting, create fast-track areas, and facilitate investment (Part 1).

Taken together, these measures are intended to increase the computing infrastructure available within the European Union. Up to this point, the argument is relatively straightforward.

The document becomes more interesting elsewhere.

The impact assessment treats dependence as a separate problem. It repeatedly distinguishes between infrastructure located in Europe and infrastructure controlled by European providers. This distinction becomes particularly visible in the proposed sovereignty framework.

Most public-sector use cases would remain open to non-European providers, provided they meet the relevant requirements. Only the highest sovereignty tiers are effectively reserved for EU-controlled providers (Part 1).

This creates a tension that runs throughout much of the document. The mechanisms for expanding capacity are largely provider-neutral. The mechanisms for reducing dependence are provider-selective. Both objectives appear within the same policy package, but they operate through different logics.

One consequence follows from this distinction. Additional capacity can be created in Europe without automatically changing who controls the market.

The capacity gap and the dependence gap are therefore related, but they are not the same thing.

Closing one does not automatically mean closing the other.

If dependency cannot be reduced through infrastructure alone, a different question emerges. What problem is CADA actually trying to solve?

That question is the focus of Part 2.

The language differs. Some discussions focus on human oversight, others on deployment approval, trust boundaries, traceability, uncertainty recognition, or Zero Trust architectures.

Yet the underlying concern increasingly looks the same.

The question is becoming less about evaluating a system in isolation and more about governing what happens when it acts.

Several recent signals point in that direction. OpenAI’s Frontier Governance Framework emphasizes deployment decisions, residual risk acceptance, and ongoing model review. Anthropic’s work on Zero Trust for AI Agents focuses on identity, authorization, and constrained execution. Gartner highlights autonomy levels, trust boundaries, and governance proportional to agent capabilities. Discussions around human oversight increasingly focus on whether oversight remains operationally meaningful under real conditions.

What I find interesting is not any individual argument. It is the fact that different fields, operating under different constraints, appear to be encountering the same governance boundary.

Independent convergence does not prove a conclusion is correct.

It can, however, be a useful indication that a structural problem is becoming visible.

Operational plausibility emerges first:

A small pilot group reports positive experiences, initial operational relief becomes visible. Modernization and fairness arguments generate support, and the system begins to appear useful and institutionally compatible.

Many other questions remain unresolved at this stage. Not only technical questions, but organizational ones:

• Who controls later system changes?

• How are problematic outputs reviewed or challenged?

• Who intervenes once usage, responsibility, and oversight begin to diverge?

These questions are often deferred into later working groups, guidelines, or governance processes.

This creates a structural asymmetry:

The organizational integration stabilizes while intervention, control, and accountability structures are only operationalized afterward.

Governance pressure therefore often becomes visible only once usage has already become organizationally stable.

Pressure appears when systems move beyond controlled settings, when audits require formal verification, or when incidents expose behavior under risk.

In these situations, evaluation changes its focus. Behavior has to be accounted for within the organization. Control has to remain possible. Responsibility has to be assigned.

This shifts the object of the decision: uncertainty becomes something that needs to be located and carried within existing structures.

As long as this assignment holds, systems remain in use. When it becomes unclear, stability weakens.

Decisions follow from this condition. They take place across selection, approval, integration, and operation, and they are revisited when pressure returns.

AI deployment is shaped by how organizations handle uncertainty under pressure.