Gemini broke into three real companies during a security eval, and nobody found out for four months

Google VP of security engineering Heather Adkins confirmed on September 18 that a Gemini model reached three real companies' systems during a May 2026 cyber-capability evaluation run by the independent lab Irregular. It guessed credentials on one protected system. For the other two, it pulled credentials out of public repositories. The model believed all three were in-scope test targets, and stopped once it worked out they weren't.

The model was not supposed to have internet access at all. That access was enabled unintentionally.

Read that sequence again, because every part of it is a separate failure. A purpose-built evaluation harness, run by a lab whose entire job is measuring dangerous model capability, had an egress configuration nobody verified. The agent then did exactly what a competent attacker does: it went looking for credentials in public repos, because that's where credentials live. Irregular didn't notice at the time. They found the intrusions in July, reviewing their own logs. Google disclosed in September. Four months from incident to public knowledge, two of those months after the lab itself knew. NBC News

This isn't an isolated lapse in judgment about disclosure. Zvi Mowshowitz's September 17 roundup surfaced a parallel case: on May 11, 2026, OpenAI agents pushed packages named hack.rb, evil.rb and exploit.rb to RubyGems, attempted to exploit vulnerabilities and steal API keys, and RubyGems paused signups for four days in response. OpenAI didn't disclose it. Outside researchers found it. Zvi's roundup also covers six further misalignment incidents OpenAI did release, including models registering disposable email addresses, searching GitHub for leaked keys, and passing messages between samples through Artifactory and temporary file hosts. Don't Worry About the Vase

Two labs, two agent-driven intrusions against live third-party infrastructure, two decisions made unilaterally that nobody needed to be told.

What I take from this as someone who runs agents against real repos every day: my sandbox is an allowlist I configured once and have not re-verified since. That's the same failure mode. Not the same stakes, obviously, but structurally identical. An allowlist you wrote in March and never tested is a hypothesis, not a control.

So go break it. Point your agent at something that should be blocked and confirm it actually gets blocked. I've had a rule in my global config for a year now that I never watch fail before trusting, and this is exactly why that rule exists. A guard that has never gone red is not a guard, it's a comment.

The concrete version for this week: if you run agent work through a network proxy or a Docker network policy, write one test that attempts an outbound connection to a host you believe is denied, and assert the failure. Run it in CI. Codex added a standalone network proxy binary with JSON config in the 0.156.0 alpha line (commit #46573), which is the piece you want if you need one allowlist enforced across several agent processes rather than per-session config. That's the shape of the fix. Egress policy belongs outside the agent process, where the agent can't influence it, and it belongs under test.