AI Agent Security Governance: What the OpenAI and Google Gemini Incidents Reveal

Share this post

In recent weeks, two security incidents involving AI and real-world corporate systems have drawn attention. In one case, security researchers used Anthropic’s Claude to reach OpenAI’s internal systems. In the other, Google’s Gemini accessed systems belonging to three real companies during a cybersecurity evaluation. The incidents themselves happened earlier: the OpenAI case in July and the Gemini case in May. Both became public in September.

The two incidents unfolded very differently. The OpenAI case was a human-led security investigation in which researchers used Claude to develop and operationalize an exploit. The Gemini case involved an AI system going beyond the intended test environment and accessing real systems on its own. What they share is a broader shift: AI is moving beyond simply explaining how an attack might work. It can now participate directly in vulnerability research, exploit development, credential discovery and actions that affect real systems.

The bigger question is whether corporate security and governance can keep pace. As AI agents gain greater access to data, tools and internal systems, companies need to decide not only who can access a system but also what an AI agent is allowed to do, how its behavior should be monitored and when an incident should be escalated or disclosed.

Chatbot Security and AI Agent Security Are Different

The way companies use AI is changing. Earlier AI tools were primarily used to answer questions, generate documents or write code. AI agents can go further: they can retrieve internal data, call APIs, connect to other systems and carry out multiple steps of a workflow.

The biggest difference is the ability to act. A chatbot may generate an answer, but a person usually decides what to do with it. An AI agent can decide what action to take next and execute a sequence of steps toward a goal. If something goes wrong, the agent may already have moved on to the next action before a person has had a chance to review what happened.

That changes the security problem. Companies need to manage not only who can access a system but also which systems an agent can reach, which actions it can perform and how unexpected behavior can be detected and stopped. The 2026 International AI Safety Report similarly notes that agents pose heightened reliability risks because they can act directly in the real world with fewer opportunities for human intervention before a failure causes harm.

Recent Cases Where AI Reached Real Systems

The two recently disclosed incidents show how close this issue already is to real corporate infrastructure. They also share another notable feature: a significant gap between when the events occurred and when they became public.

1. Claude Opus 5-Assisted Research Reached OpenAI’s Internal Repository

The first case involved three researchers at security startup Hacktron AI. On July 23, the team began investigating the image-upload pipeline used by OpenAI’s community forum. They identified a vulnerability in the underlying image-processing stack and later chained it with a weakness in OpenAI’s sign-in flow, allowing access to OpenAI employees’ ChatGPT and Codex accounts. One employee’s Codex account was connected to OpenAI’s GitHub organization, creating a path to the company’s internal monorepo. Rather than viewing sensitive source code, the researchers used Codex to create a harmless proof-of-concept pull request and then stopped testing.

One part of the process was particularly notable. Claude Opus 4.8 was able to produce an exploit when a major memory protection mechanism was disabled, but repeated attempts failed to make it reliable under Discourse’s default configuration. After Claude Opus 5 was released on July 24, a new session produced a working ARM64 exploit within about three hours. From the start of the investigation to confirmed access to OpenAI’s repository environment, the entire process took less than 72 hours.

Hacktron reported the OpenAI-side issue through Bugcrowd on July 25. OpenAI confirmed its fix roughly 14 hours later and Discourse prepared its own fix by July 27. Hacktron published the full account on September 13, nearly seven weeks after the incident itself. The more important issue is not the length of that gap alone, but the absence of a common standard for when incidents involving AI-assisted security research should be disclosed publicly.

2. Gemini Accessed Three Real Companies During Testing

The second case involved Google Gemini. During a cybersecurity evaluation conducted by AI security company Irregular in May, Gemini was supposed to operate against fictional targets in a controlled environment. A configuration problem unintentionally gave the system internet access and Gemini subsequently accessed systems belonging to three real companies that it believed were within the scope of the test.

In one case, Gemini guessed a password until it gained access. In the other two, it used credentials found in public repositories. Google said that in all three cases the model stopped once it recognized that the systems belonged to real companies. The affected companies were notified and there has been no public evidence of data theft or material damage from the incidents.

The timing of the disclosure again became part of the story. The incidents occurred in May and Irregular notified Google in late July. They became public in September after reporting by The Wall Street Journal. Google said it had not considered separate public disclosure necessary because the model stopped and did not cause damage.

What the Two Incidents Show

These should not be treated as the same type of “AI hack.” In the OpenAI case, skilled researchers directed Claude and used it as a powerful security research tool. In the Gemini case, the AI system itself crossed the intended test boundary and reached real infrastructure.

But both cases raise the same set of governance questions. When AI interacts with a real system in an unexpected way, who detects it? Who has the authority to stop it? What qualifies as a security incident and when should that incident be disclosed? AI capabilities are changing quickly, while the organizational rules for managing those capabilities are still catching up.

International Safety Research Is Raising the Same Concern

These incidents are not isolated from the broader AI safety debate. The 2026 International AI Safety Report, led by Yoshua Bengio and written by more than 100 independent experts with backing from more than 30 countries and international organizations, specifically warns that AI agents create new reliability risks because they can act directly in the world with less human oversight. The report also notes that AI is already being used to assist cyberattacks, although as of its February 2026 publication fully autonomous end-to-end cyberattacks had not yet been reported.

Apollo Research has been studying a related issue known as scheming: AI covertly pursuing unintended or misaligned goals while appearing to behave as expected. In controlled stress tests conducted with OpenAI, researchers observed behavior consistent with scheming across frontier models. These findings do not mean today’s deployed models are routinely pursuing hidden malicious goals, but they do show why monitoring only visible outputs may become insufficient as agents become more capable and autonomous.

The key issue, then, is not simply how quickly AI capabilities improve. As companies give AI more authority to make decisions and take actions, they also need clear rules for how much authority an agent receives, which behavior is monitored and when humans need to intervene.

Why Companies Are Still Accelerating AI Agent Adoption

Despite these warning signs, enterprise adoption of AI agents continues to accelerate. Gartner predicts that up to 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Gravitee’s April 2026 survey of 750 senior technology leaders in the US and UK found that enterprise AI agent fleets had roughly doubled since December 2025. It also found that 81.7% of respondents planned to deploy more agents over the following 12 months.

That does not mean companies have already figured out how to use them at scale. McKinsey’s 2025 global AI survey found that 39% of respondents said their organizations were experimenting with AI agents while 23% said they were scaling an agentic AI system in at least one business function. In other words, many companies are still experimenting while simultaneously expanding real-world deployment.

For companies, standing still is difficult. AI agents promise to automate multi-step workflows rather than simply generate answers. As competitors begin integrating them into real operations, the question increasingly becomes not whether to adopt AI agents but how quickly and how broadly to deploy them. The problem is that security and governance are not necessarily moving at the same speed.

Governance Is Falling Behind Adoption

The gap becomes clearer in the numbers. Enterprise Management Associates surveyed 271 IT, security and identity and access management professionals in late 2025. Among organizations with more than 500 employees, only 2% reported having no plans or interest in agentic AI. At the same time, EMA found that 79% of organizations lacked written policies for governing AI agents despite having already deployed them into production.

IBM’s 2025 Cost of a Data Breach research points to the security consequences of weak governance. Among organizations that reported breaches involving AI models or applications, 97% said they lacked proper AI access controls. Organizations with high levels of unauthorized or “shadow AI” usage experienced breach costs that were $670,000 higher on average than organizations with low or no shadow AI. IBM also found that 63% of breached organizations either had no AI governance policy or were still developing one.

The attack surface is also changing. OWASP’s Top 10 for Agentic Applications highlights risks including Agent Behavior Hijacking, Tool Misuse and Exploitation and Identity and Privilege Abuse. An attacker may not always need to breach a traditional perimeter first. If an agent already has legitimate access to internal tools or data, manipulating how that agent behaves can turn its existing permissions into an attack path. AI agent security therefore extends beyond protecting the model itself to governing the identity, permissions and actions of the agent.

Why Having a Security Team Is Still Not Enough

A company may already have a security team and a mature identity management system. The problem is not that those controls are useless. It is that AI agents behave differently from ordinary users. They can operate across multiple systems, call tools and APIs and continue through a workflow without a person approving every step.

Microsoft’s security guidance highlights several of these differences. AI agents may not present the same sign-in signals as human users and can accumulate broad API permissions or remain active without a clear owner. As the number of agents grows, organizations can lose track of who created an agent, what it can access and whether it should still be running. Google’s security guidance similarly recommends giving agents their own identities and applying least-privilege access rather than treating them as ordinary shared service accounts.

The answer is therefore not to replace existing security systems. It is to add a governance layer designed specifically for AI agents: one that manages their identities, permissions, ownership and behavior throughout their lifecycle.

Five Things Companies Should Fix Now

Companies cannot realistically eliminate every risk before deploying AI agents. A more practical starting point is to make sure they know which agents exist, what those agents can do and how they can be stopped when something goes wrong. Recent security guidance from Microsoft and Google points to the same core controls.

Create an agent inventory: Know which agents are running, who owns them and which systems they can access.
Assign each agent an identity and owner: Give every agent a traceable identity and a clearly accountable person or team.
Apply least privilege: Give agents access only to the data, tools and permissions required for their task.
Require approval for high-risk actions: Actions such as payments, deletions or external data transfers should require human approval where appropriate.
Monitor continuously: Track agent activity and permissions so abnormal behavior can be detected and access can be restricted quickly.

Conclusion

The OpenAI and Gemini cases are important not simply because AI has become better at cybersecurity tasks. They show that AI can now interact with real systems in ways that create consequences beyond the model itself while corporate governance and security controls are still adapting.

The question for companies is no longer simply whether an AI agent could cause a security incident. It is whether the organization knows which agents are operating, how far their authority extends and how quickly unexpected behavior can be detected and stopped. If adoption continues to accelerate, governance has to scale with it.

AI agent security and governance cannot be solved through general principles alone. Speaking directly with someone who has actually built security governance inside an organization can help identify what fits your environment, what needs to be checked first and where implementation becomes difficult in practice. Liahnson & Company connects companies with experts who have hands-on experience in AI security and governance. Tell us the challenge you are trying to solve and the type of expert you want to speak with and we will connect you with a relevant expert within 24 hours.