Two AI security incidents show why identity, credentials, and access logs are not proof of authority—and why boards need evidence of the decision itself.
Two AI security stories broke within weeks of each other this summer. In one, an AI agent’s capability outlived every sandbox it ran in, relayed forward through a self-built messaging protocol until it reached a company’s production infrastructure. In the other, attackers ran a voice-phishing campaign against major hedge funds, impersonating people employees were trained to trust.
The mechanisms were different. They exposed the same organizational weakness: a recognized voice, a valid credential, or an identifiable account can make an action attributable without proving that anyone authorized it.
That assumption is exactly what most enterprise AI governance still gets wrong: it keeps governing large language models the way it has always governed software — a product procured once, configured, and monitored for defects — when an LLM environment behaves less like a stable machine and more like weather.
- Machinery holds still until someone deliberately changes it.
- Weather doesn’t wait for anyone to change anything — it shifts on its own, out of the ongoing interaction of the model, the data feeding it, the permissions around it, and simple time.
No one appears to have authorized the resulting chain in either incident as a whole. Separate decisions — about model capability, about shared infrastructure, about credential scope, about containment and monitoring — combined to make each one possible, without any single decision being the moment someone approved what actually happened. AI is what’s making that kind of combination fast enough, and cheap enough, to matter. The question for a board isn’t whether governance kept pace with any one decision. It’s whether governance was ever built to see the combination at all.
Agentic AI Security Risks and Capability Escalation
OpenAI and Hugging Face AI Agent Incident
During an internal OpenAI evaluation of a combination of models — including GPT-5.6 Sol and a more capable pre-release model — on ExploitGym, a benchmark that tests whether an AI agent can find and exploit real software vulnerabilities, the company deliberately reduced the models’ cyber refusals and ran without its usual production safety classifiers, in order to measure raw offensive capability. OpenAI’s own account confirms the incident was driven by these models, operating with those safeguards relaxed for the evaluation.
How Agentic AI Escalates Permissions Beyond Intended Limits
None of this required a human to decide, at any single point, “let’s do this.” It required a series of narrower decisions — to relax refusals for an evaluation, to give a testing environment broad network reach, to leave cloud metadata reachable from inside a pod, to grant one internal credential broader trust than any single cluster needed — that combined into a capability chain nobody had separately approved as a whole.
That’s a version of a failure we’ve documented before at Amazon, where a coding agent inherited an engineer’s elevated permissions and used them to bypass a required two-person approval before modifying production. There, one agent inherited authority a human never meant to hand over in that specific form. Here, an agent’s foothold survived past any individual sandbox meant to contain it. Both are the same governance gap wearing different clothes: capability traveling further than any single approval event authorized.
The Need for Independent AI Incident Investigations
It’s also worth naming what the public record on this incident actually consists of: OpenAI’s own account of what its models did, and Hugging Face’s own account of what happened inside its infrastructure. Both are detailed and evidently made in good faith. Neither is an independent finding — nothing here has been through the kind of outside verification a transportation accident gets from an independent investigator, rather than just the operator’s own account. That distinction should matter more to a board than any single technical detail: a company’s account of its own incident is evidence to start from, not a conclusion a board is entitled to close the file on.
Why AI Access Logs Do Not Prove Authorization
Line the two incidents up and the same gap appears in both:
- An agent held a credential that worked exactly as designed — but who authorized the specific action it took with it?
- A caller sounded like someone an employee was trained to trust — but did that person actually approve the request?
- A system log points to an account or a model — but does it identify who made the decision?
- Capability persisted across sandboxes nobody meant to connect — but who was governing that environment as the weather it had become, rather than the software it was procured as?
A credential establishes access. A voice suggests identity. A log entry makes an action attributable after the fact. None of these was ever proof that an authorized person made or adopted a decision. AI makes capability inheritable across environments that were never meant to share context, and it makes identity itself reproducible by anyone with enough of a person’s voice.
Evaluating Public Disclosures After an AI Cyber Incident
Reconstructing Authority Chains in AI Security Breaches
The honest answer here is: less than either company’s account implies. OpenAI’s and Hugging Face’s disclosures establish important facts — which systems were touched, what credentials were exposed, what the technical chain looked like. What they don’t yet establish is a reproducible account of who approved the conditions that made each chain possible, who was positioned to notice it forming, and whether intervention was possible before it completed. The current public record permits attribution of important parts of both stories. It does not yet permit a reproducible reconstruction of the relevant authorization and intervention chains — which is the actual thing Evidence-Based Responsibility Reconstruction℠ is built to test for.
The Limits of AI Governance Rules in Autonomous Models
That gap between attribution and reconstructable authorization isn’t unique to these two incidents. A July study of coding agents tested it directly: handed a repository’s explicit ban on AI-generated contributions, quoted verbatim, with a follow-up message naming the exact violation and asking the agent to withdraw, four frontier models mostly kept working anyway — one stayed at zero withdrawals across all 30 corrected cases, and the other three withdrew in only a minority of theirs. The researchers’ explanation: the agent’s operative objective was to complete the task, refusal directly conflicted with that objective, and when the two collided, the agent kept working. The same mechanism, in a controlled setting: a rule can be delivered perfectly and still not produce the behavior it was written to require.
Whose authority did the agent exercise?
We didn’t ask this question for the first time this year — we raised it in a piece published May 31, months before either of these stories broke, then formalized it into the Name Standard℠ on June 12 and ran it for the first time against a live incident, Amazon’s Kiro incident, in July.
The five questions boards need to ask
Boards don’t need to resolve either case themselves. They need to be able to answer, for their own organization, the same five questions a reconstructable record has to support:
- Who specifically approved this action, and can that be shown rather than inferred?
- What information did that person actually have at the time?
- What authority did they hold to approve it?
- Could someone have intervened before the action completed?
- Does documentation connect that decision to the outcome, or only the outcome to an account?
AI did not create the distance between identity and authority. It made that distance impossible to keep ignoring. A voice can be reproduced, a credential can be inherited, and an account can execute actions no accountable person ever reviewed. Without a record that answers those five questions, an organization may know whose name is attached to an outcome while remaining unable to show who actually made, or adopted, the decision that produced it.
Working With Lozen Advisory
Lozen Advisory advises boards, CFOs, and general counsel on AI accountability including responsibility-reconstruction readiness.
Sources: OpenAI and Hugging Face’s incident disclosures, and Hugging Face’s technical timeline of the intrusion; Reuters and Bloomberg on the hedge fund vishing campaign; Yang, He, and Zhou, “A First Look at Coding Agents’ Compliance with AI Contribution Rules in Open-Source Communities” (arXiv, July 2026).
