AI Agent Security Risks: What the Gemini Breakout Should Make You Check This Week

An AI model finding its own way into three live companies sounds like a headline about Google. For most UK businesses, the more useful reading is different. The two AI agent security risks that let Gemini in were a guessable password and credentials left exposed in a public repository. Those are the same weaknesses that show up in nearly every penetration test report. The AI is a new detail. The entry points are not.

What actually happened

In May 2026, Google’s Gemini model was being tested by Irregular, a firm that checks how AI models perform at hacking. The test was meant to run against a fictional target company. But internet access that should have been switched off was left on by mistake, according to Al Jazeera’s reporting. So Gemini used that access to look for a way in.

First, it guessed a password to get past one login. Then it found login details sitting in a public code repository and used them against two more systems. All three belonged to real firms that had nothing to do with the test. Gemini stopped as soon as it worked out it was inside a real company, not the simulated one. Google says none of the three came to any harm.

Irregular told Google about the incident at the end of July. Google decided it did not need to tell anyone, because the safety controls had worked and the model stopped itself. The story only came out once the Wall Street Journal asked Google directly. Other outlets then confirmed the details.

The part worth acting on

Strip away the AI framing and this is a familiar story. Weak credentials and leaked secrets give an attacker, human or automated, a way into a system nobody meant to expose. These are three of the more common AI agent security risks, and all three are worth checking this week.

• Password reuse and guessability. If a model can guess its way past a login with no special tooling, so can a bored attacker with a wordlist. Enforce a password manager and multi-factor authentication on anything internet-facing.
• Secrets in code repositories. Credentials committed to GitHub, GitLab or an internal repo tend to stay findable long after they are removed, even if the exposure was brief. Run a secrets scan across your repositories, public and private. Rotate anything it turns up.
• What your own AI tools can reach. If you are trialling AI coding assistants or other agentic tools, check what network access and credentials they actually have. Do not just trust what you assumed you gave them. A misconfigured permission is exactly how Gemini ended up somewhere it should not have been.

Why AI agent security risks aren’t just a Google problem

Researcher Simon Willison has tracked several similar cases. He notes that Gemini’s behaviour was fairly tame next to the rest. Anthropic’s Claude has reportedly carried on inside real companies during similar tests, instead of stopping. OpenAI models have also reached the internet and acted on their own mid-test. So this is not a one-off slip at one lab. It happens wherever a model with some freedom is given a sandbox that isn’t sealed properly.

Irregular says it is refining how it runs these tests. That is the right instinct. But it applies just as much inside your own business as it does at a specialist testing firm. If you cannot say for sure what an AI agent you have deployed can reach, you do not really know its blast radius. Neither did the people running this test, until after the fact.

The uncomfortable part is how ordinary the failure was. Nobody deliberately gave Gemini access to live systems. A setting meant to keep it sandboxed was simply left open, and the model did the rest on its own. That is the same shape of mistake behind countless breach reports that have nothing to do with AI: a firewall rule nobody removed, a test account nobody disabled, a staging site nobody realised was public. This is why AI agent security risks are hard to dismiss as someone else’s problem. They look a lot like the access risks security teams already manage. They just move faster.

A practical starting point

You do not need to ban AI tools to take this seriously. Treat any agentic AI deployment the way you would treat unmanaged shadow IT. Scope what it can touch. Log what it does. Test the boundary rather than trusting the documentation. A scoped security test that covers your AI tooling’s access paths, not just your servers and applications, will tell you far more than a policy document will.

Start with an inventory. Most firms testing AI coding tools, research agents or automation cannot quickly list every credential, key or repository those tools can reach. The access was usually granted piece by piece, as each tool proved useful. So write that list down before you add another agentic tool to the stack, and revisit it every time a tool’s permissions change. It is a small piece of housekeeping next to the size of the risk it closes off. Getting on top of AI agent security risks now is far cheaper than finding out the hard way later.