Your AI Provider May Not Call It an Incident. Should You?

In May 2026, a Gemini model accessed systems belonging to three real companies during a third-party cybersecurity evaluation. Reporting published in September said the model found public information, guessed credentials and entered systems it believed were part of the authorized exercise. Google said the model stopped in each case after recognizing that the targets were real.

The testing environment reportedly contributed to the event. The model was not supposed to have internet access, but the test provider, Irregular, told The Wall Street Journal that connectivity had unintentionally remained available. Google said the event was a case of mistaken identity rather than model misalignment and stated that the affected organizations were notified.

Those facts matter. They also reveal a governance question that extends well beyond one model or provider: who decides what counts as an AI incident?

The provider may focus on the model's behaviour and whether it deliberately violated instructions. The testing organization may focus on an incorrectly configured environment. The affected company may focus on unauthorized access. A customer using the technology may need to consider whether its vendor assessment, deployment conditions or risk rating should change.

All of these perspectives can coexist. They do not necessarily lead to the same classification or response.

Terms such as misalignment, containment failure, configuration error, unauthorized access and security incident are not interchangeable. Each term frames the event differently and can influence whether it is escalated, disclosed, investigated or treated as evidence in a future risk decision.

A provider may reasonably conclude that a model did not exhibit misalignment because it stopped when it recognized the targets were outside the exercise. A customer may still conclude that the event exposed a material failure of authorization controls. The distinction is crucial: responsible governance does not require an organization to dispute the provider's technical explanation, but it does require the organization to evaluate the event through its own risk, legal, operational and contractual obligations.

The central question is not only, "Did the model intend to cross the boundary?" It is also, "Why was crossing the boundary technically possible?"

Intent is an unreliable control for an autonomous system. A model cannot be expected to infer organizational authorization from context alone, especially when tools, credentials and network access allow it to reach systems outside the approved scope. Authorization must be explicit, machine-enforceable and continuously monitored.

Clariantix recommends that AI incident and vendor-review workflows preserve two separate fields.

Provider classification records how the developer, vendor or test provider describes the event. It should capture the provider's terminology, stated cause, supporting evidence, affected systems, containment measures and corrective action.

Customer governance classification records the organization's independent assessment. It should address the actual or potential impact, the control that failed, the degree of unauthorized access, contractual and regulatory relevance, and the response required before use continues or expands.

Separating these fields prevents a vendor's terminology from becoming the customer's conclusion by default. It also preserves the evidence trail. If additional facts emerge, the organization can revise its own classification without rewriting what the provider originally reported.

For cyber testing and other high-agency uses, written instructions are not enough. Organizations should establish scope allowlists that identify the only permitted domains, hosts, accounts and actions. Network controls should block all destinations outside that scope. Credentials should be purpose-specific, time-limited and incapable of granting access beyond the approved environment.

Monitoring should detect unexpected destinations, credential attempts and changes in the agent's action path. A kill mechanism should allow the organization to revoke credentials, isolate the environment and stop execution without relying on the agent to recognize that it has made a mistake.

These controls apply beyond security testing. The same principle is relevant when AI agents interact with client portals, project platforms, cloud environments, research databases or procurement systems. If the boundary matters, it should be enforced by architecture and policy together.

Executives do not need to determine whether this event proves a general flaw in Gemini. The disclosed facts do not support that conclusion. They do support a narrower and more useful lesson: provider classification and customer accountability are different governance functions.

Organizations should update their incident and vendor-review processes so that external explanations remain evidence rather than verdicts. They should also require technical proof that agent boundaries are enforced, including allowlists, network restrictions, explicit target authorization, credential controls, monitoring and tested isolation procedures.

An AI provider may decide that an event does not meet its definition of misalignment. Your organization must still decide whether a control failed, whether risk changed and what must happen next.

That decision belongs to your governance system.