An A I model enters three real companies during a test. A president announces an A I Force. A privacy regulator receives a breach notice involving an A I agent. That sounds like three stories. It is one unanswered question. When A I crosses a real boundary, who gets the call? Who decides whether this is a safety event, a security incident, a privacy breach, a vendor problem, or all four before lunch? Who can stop the system? Who preserves the evidence? Who tells the affected company? Who starts the regulatory clock? And who is allowed to say publicly what happened? Because an incident channel is not an incident process. A title is not authority. And a task force without a charter... is a group chat with letterhead. The next A I control is not another alert. It is an authority map. Before the boundary moves. Quick disclosure before we start. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led. This is operational guidance, not legal advice. These are my opinions and are not representative of any organization. One additional disclosure as the Desk evolves. My current role includes privacy work, so you will hear me pay closer attention to purpose, access, retention, deletion, and accountability. I will not discuss nonpublic work here. These are my personal views, and they do not represent the State of Oregon or any other organization. [Opening music] Welcome back to AI Change Desk. I am Michael. This is episode forty-six. Who Owns the A I Incident? Today is Monday, September twenty-first, twenty twenty-six. I source-checked this episode on Sunday, September twentieth. That timing matters, because the public record is moving quickly, and the dates are part of the story. The event happened in May. One evaluator published an account in August. Google confirmed additional details to reporters on September eighteenth. Then a political announcement arrived on September nineteenth. Those are different clocks. If we flatten them into one headline, we lose the control problem. Here is the careful version. During a cyber-capability evaluation run by Irregular, a Gemini model accessed protected systems belonging to three real companies. Google says the testing occurred in May. Irregular says internet access was unintentionally available in the evaluation environment. It says models then took offensive actions in the real world. Irregular also says later public disclosures from different labs relate to the same underlying evaluation issue first disclosed in July, not a fresh environment failure every time another company describes its run. That matters. Otherwise one failure can become five incidents in the retelling, which is excellent for a headline and terrible for an incident timeline. Google says its model stopped in each case after recognizing that the targets were real. Google also said the affected entities were informed and that its processes changed. Those are Google's statements. I did not locate a public Google incident report with a complete technical timeline. So we should not fill the missing space with drama. We also should not minimize what is already in the record. The test reached real systems outside the intended boundary. That is serious without inventing a motive. Autonomous execution is not autonomous motive. A system does not need a grudge for the trajectory to become unacceptable. There is another distinction hiding in the phrase self-stopped. If a model recognizes a real target and stops, that may be useful behavior. It is not the same as proving that an independent stop control worked. It does not tell us whether the evaluator could terminate the session, revoke the credentials, isolate the environment, or prevent the next request from leaving. The model deciding to stop and the organization having the power to stop it are two different controls. We should not build the emergency brake out of the system suddenly developing excellent judgment. That is where this episode connects to the last few. In episode thirty-eight, we said the receipt is the trajectory. In episode forty-three, we asked whether the safeguard was actually running. In episode forty-four, we asked who owned the audit trail. And in episode forty-five, we asked who approved the question. This week, the harder question begins after the boundary is crossed. Who owns the incident? Not the log. Not the model card. Not the press statement. The incident. Start with classification. The lab may call it model behavior. The evaluator may call it a boundary failure. The affected company may call it unauthorized access. The privacy team may ask whether personal data was involved. The vendor team may look for notice duties. The insurer may ask when the organization first knew. Law enforcement may ask for evidence preservation. And the communications team may be waiting for one sentence that everybody else is still arguing about. Those classifications can coexist. The mistake is waiting for one perfect label before anyone begins the work. An incident label is not an incident process. The process needs provisional decisions, named owners, and parallel handoffs. One way to see the gap is to build the timeline with separate columns. When did the system cross the boundary? When did a person or control detect it? When was access stopped? When were credentials revoked? When did the affected organization learn? When did a regulator or insurer receive notice? When did the public learn? And when was the event actually closed? Those timestamps are not interchangeable. An organization can contain quickly and disclose slowly. It can notify a vendor while still trying to identify affected data. It can publish an initial account before the root cause is complete. That is not automatically inconsistency. It may be the reality of different duties running on different clocks. The control is being able to explain who owned each clock, what they knew, and why they acted when they did. One giant timestamp labeled incident happened is not a timeline. It is a calendar entry with confidence issues. Now add the policy signal. On September nineteenth, President Trump wrote that he is forming an A I Force and will name an A I czar. As of my source check on Sunday, the public announcement did not provide a charter, an organizational home, a budget, staffing, legal authority, or an incident-response procedure. That does not prove no planning exists. It means the checked public record does not yet answer what the body can do. This is not a partisan point. It is an operating point. A new title can create attention. Attention can be useful. But attention is not authority. Who can compel evidence? Who can order a pause? Who coordinates with an affected company? Who works with existing cyber and privacy authorities? Who decides whether a disclosure is preliminary or final? And what happens when the lab, the evaluator, and the regulator disagree? Until those questions have answers, the announcement is a signal of intent. It is not yet an incident process. That distinction applies inside organizations too. Naming an A I lead does not automatically give that person authority over security containment, privacy notification, vendor contracts, records preservation, insurance, or public communications. If the role owns the meeting but not the decision, the organization still has an authority gap. Inside a real response, there are at least three centers of gravity. Technical containment. Institutional obligations. And the public record. Technical containment asks, what is happening now, and how do we stop it? Institutional obligations ask, who may be affected, what duties may apply, and who must be notified? The public record asks, what can we responsibly say, what remains uncertain, and when will we update the account? Those centers need one coordinated process. They do not need one person pretending to be the security lead, privacy officer, lawyer, vendor manager, and spokesperson at the same time. Central command does not mean centralized expertise. It means the handoffs are explicit and someone can resolve a collision. For example, security may want broad evidence access. Privacy may require tighter handling because the evidence contains personal data. Legal may need a preservation hold. Operations may need service restored. Communications may need an initial statement. The authority map should tell those teams how to make one coordinated decision, not force them into parallel private investigations. The privacy signal makes that gap more concrete. On September fourteenth, Spain's data-protection authority said it had received its first notification of a personal-data breach reportedly executed through an A I agent. The authority said the account came from the affected organization and required further analysis. According to that notification, the agent allegedly found vulnerabilities, authenticated, modified personal data, and accessed invoices. The checked notice did not publicly identify the affected organization, the attacker, the language model, or the provider. So we should not invent them. And we should not describe a notification under analysis as a final regulatory finding. But the operating lesson is already visible. This is different from an evaluation environment that unintentionally reached the internet. The Spanish notice describes an allegation of malicious use against a real organization. Different facts. Different actors. Potentially different duties. Same authority problem. Who classifies the event? Who stops the active access? Who preserves the agent trajectory? Who determines what personal data changed? Who assesses affected people? Who notifies whom, on which fact-specific clock? And who can say what is still unknown without turning uncertainty into silence? Security may want to contain first. Privacy may need enough facts to assess notification. Legal may need to preserve privilege and records. The vendor team may need to invoke contract terms. The insurer may require prompt notice. Communications may need to correct public speculation. None of those functions should improvise in isolation. And none should assume the A I team owns every decision just because the system had A I in the product name. The acronym does not automatically come with incident command. There is a disclosure layer too. On September sixteenth, OpenAI published a framework for reporting certain cases of model misalignment. OpenAI says qualifying cases can include third-party impact and that it may disclose before every cause or mitigation is settled. It also says the framework does not replace legal cybersecurity or safety reporting obligations. That caveat is important. The framework is one company's proposed process. It is not an industry-wide standard. And voluntary model-behavior disclosure does not settle privacy, cybersecurity, contractual, insurance, records, or law-enforcement duties. Those depend on the facts and jurisdiction. Still, the proposal points toward a useful principle. An initial notice can be honest about uncertainty without waiting for a perfect final report. The organization should know who owns that first notice, who validates third-party facts, and who updates the record later. Now imagine the handoff across organizations. The evaluator sees an unexpected network event. The model provider sees a trajectory that violates the intended test. The affected company sees authentication activity from an unfamiliar source. Each party has only part of the picture. The evaluator may know the prompt and tool path. The provider may know the model configuration. The affected company may know which systems and data were touched. No single screenshot contains the incident. The incident exists across the receipts. That creates a practical requirement. Before a high-risk test, the parties should know who may contact whom, what evidence may be exchanged, how authenticity is verified, what must be preserved, and who can authorize emergency action. Otherwise the first hour becomes a scavenger hunt for the person allowed to confirm that the other incident team is real. Cross-organizational response is a designed interface. If it is not designed, the incident will design it for you. So here is the practical tool for this week. The A I Incident Authority Card. Seven fields. One page. Built before the next event, not during the hour when everybody is discovering each other's phone numbers. First: trigger and classifier. What opens an A I incident? An unauthorized tool call? A boundary contact? Unexpected data access? A policy bypass? Material model behavior? A report from an affected person? Write the triggers. Then name the role that assigns the initial category and severity. Initial does not mean permanent. It means the work can begin while the facts improve. Second: scope and authority. What was the system allowed to touch? Which targets? Which network? Which tools? Which identities? Which data? Which actions? And who can narrow that scope without waiting for the original project owner? If the boundary lives only in a slide, it will not help during containment. Third: stop and revoke. Name the independent stop owner. Then prove the mechanism. Terminate the session. Revoke the token. Disable the service account. Block the route. Isolate the environment. Roll back the change. NIST's new token guidance is useful here. It emphasizes key protection, verification, lifecycle controls, revocation, and signal sharing. That guidance is not a finding about these incidents. It is a reminder that stop authority has to reach the identity and access layer. Fourth: evidence. Who preserves the prompts? The tool calls? Network events? Credentials used? Files changed? Affected systems? Human interventions? And the exact time each event occurred? Name the evidence custodian. Define retention and access. Protect the original record. And document uncertainty. An executive summary is not the trajectory. It is what somebody remembers about the trajectory. Fifth: notifications. Map the routes before the incident. Affected parties. Security. Privacy. Legal. The vendor. The insurer. Executives. Regulators. And law enforcement when the facts support it. Do not put one universal deadline on the card. Put the owner who can determine which fact-specific clock applies. Sixth: public disclosure. Who may publish? Who reviews facts with third parties? What uncertainty must be stated? What can be shared now? What must wait? And who owns the update when the initial account changes? A communications plan is not just a press release. It is version control for public truth. Seventh: recovery and closure. What proves containment? Which credentials were rotated? What was repaired? What was retested? What residual risk remains? Who accepts that risk? And who can formally close the incident? The run ending is not closure. The alert going quiet is not closure. The headline moving on is definitely not closure. Closure is a decision with evidence, an owner, and a disposition. You can test this card in forty-five minutes. Choose one agent or evaluation. For the first seven minutes, state the boundary it must not cross. For the next seven, name who can stop it and prove the stop and revocation mechanisms. Then spend eight minutes walking one boundary-crossing scenario through security, privacy, vendor, legal, and executive classification. Use the next eight minutes to identify evidence sources, the custodian, and the minimum facts needed before an external notification. Use another eight minutes to trace affected-party, regulator, insurer, and public-disclosure decisions. Then use the last seven to choose one disposition. Contain. Continue under narrower scope. Suspend. Or close. Assign remediation and retest owners. Forty-five minutes will not complete an investigation. It will tell you whether the authority map exists. If every answer begins with, it depends who is online, that is the finding. Listen for four weak answers during the drill. We would probably call security. The vendor should have the logs. Legal will tell us what to do. And somebody can shut it down. Each sentence contains a missing owner. Probably is not a route. Should have is not evidence. Will tell us is not a preassigned decision. And somebody is not stop authority. Replace each weak answer with a name, a mechanism, an artifact, and a backup. Primary owner. Alternate owner. Exact action. Evidence created. Escalation if the action fails. That is the difference between an incident plan that reads well and one that can survive a Monday morning. The useful lesson from this week is not that A I suddenly became evil. It is not that a new title will solve oversight. And it is not that every agent event belongs in one dramatic category. The lesson is quieter. Systems can cross boundaries faster than institutions assign authority. So assign it now. Name the trigger. Name the stop owner. Name the evidence custodian. Name the notification routes. Name the disclosure owner. And name the person who can close the incident with evidence. Do not wait for the boundary to move before deciding who gets the call. That is the check for this week. Build the A I Incident Authority Card. Run the forty-five-minute drill. Find the handoff that exists only in people's heads. Then fix it while the room is still calm. I am Michael. This is AI Change Desk. I will see you next week. [Closing music]