Gemini Hacked Three Companies: What It Means for You

You connected an AI assistant to your inbox, your shared drive or your CRM because it saves you hours, and this week you read that Gemini hacked three companies. A day later came a second headline: researchers used Claude to hack into OpenAI. If a tool from one of those same companies is reading your customer email right now, the question in your head is simple: could it be turned against you? The short answer is that these stories are a reason to check what your AI tools can reach and do, and they do not show ordinary business agents breaking into anyone. One was a cybersecurity test that reached real systems after an unplanned internet connection, and the other was security research that was reported and paid for. Both still carry lessons you can act on this week, and neither one means you have to pull out tools that are working. What matters is the gap between those events and the assistant sitting in your own accounts, and the few limits that keep a useful tool from becoming a costly one.

Your Risk Comes Down to What Each Connected AI Tool Can Do Alone

The assistant in your inbox is only as dangerous as the permissions it holds. Neither of this month's incidents involved a small-business email, CRM or bookkeeping agent attacking its own customers, and no source in either story shows that happening. The exposure that security bodies describe for tools like yours is different and more ordinary: an agent reads something it should not trust, such as an email, an attachment or a web page, while the account it runs under can send mail, change files, spend money or expose customer data.

Google says this plainly about its own product. Its Gemini in Chrome safety guidance warns that an agent can run into malicious instructions inside a website, email, document or video, and that possible results include posting private email or document data, sending Gmail to an outside service, and exposing information from connected apps. Google adds that its safeguards do not guarantee protection, and tells users to watch sensitive tasks, read confirmations before approving them, and use Stop or Take over when something looks wrong.

That gives you a practical way to sort your tools. An assistant that only answers questions in a chat window, with no connected accounts, has very little it can damage. An agent that can read your inbox and also send from it, or can see your files and also share them, sits in a different category. The question to ask about every tool is not "is this AI safe?" but "what can this account do if the AI gets it wrong?"

The details Google shared about the Gemini test point at something even more familiar. According to Google's statement as reported by Reuters, the model guessed login credentials in one case and, in two cases, used credentials that had been left exposed in public code repositories. Those are the same weaknesses human attackers use, and you can close them whether or not you use AI at all.

Gemini Reached Three Real Companies During Irregular's Security Test

In May 2026, the independent firm Irregular ran a cybersecurity evaluation of Gemini. This was a sanctioned test of the model, not a customer deployment of a Gemini product and not an attack ordered by Google. The test environment was supposed to be closed off from the internet, but it had unintended internet access.

Inside that environment, Gemini found public information and used credentials to reach three real companies it believed were part of the test. Google said the model stopped in each case once it recognized the target was real, and that the three companies were notified. Google was told about the events in late July and confirmed them publicly on September 18, in a statement attributed to its security vice president, Heather Adkins. The Guardian's report on the Google statement carries the same account of an evaluation that reached real systems.

What Google has not published matters just as much for how you read the coverage. As of September 23, there is no standalone Google incident report naming the three companies, the model version, what data was touched, or a technical timeline. If a post you read names the companies or describes stolen data, treat that as unconfirmed until Google or Irregular publishes it.

For your business, the useful takeaway sits in the method rather than the model. A guessable password and a login left in public code let an automated test walk into real accounts. An automated attacker, with or without AI, can do the same. Unique passwords, credentials kept out of shared code and documents, and multi-factor sign-in on every account an agent touches are the first repairs, and they cost very little.

Researchers Used Claude to Build a Disclosed Exploit Against OpenAI

The second story is a separate kind of event, and it helps to keep the two apart. On September 13, 2026, the security firm Hacktron AI published its own write-up, "Hacking OpenAI". Three researchers chained together two weaknesses: a vulnerable image-processing path in OpenAI's community forum, which runs on hosted Discourse software, and a flaw in OpenAI's single sign-on system.

People chose the target and directed the work. Claude helped them develop the exploit, including an autonomous loop that the researchers ran against their own copy of the Discourse Cloud software, not against OpenAI. On July 25, they gained access to several OpenAI employee ChatGPT and Codex accounts and showed they could reach an internal code repository by opening a harmless pull request. They reported the problem and stopped testing at about 15:30 UTC.

OpenAI confirmed its side was fixed at 22:49:45 UTC, roughly 14 hours after the report, and paid the researchers $6,500 on September 1. OpenAI runs a Safety Bug Bounty program for reports like this, though Hacktron itself says the forum target was outside the program's stated scope, so calling it a fully pre-approved test would overstate it. TechCrunch covered it on September 18 under the headline that researchers used Anthropic's Claude to hack into OpenAI. No matching statement from Anthropic about the event could be located.

Read side by side, the two events share one thing that applies to you: in both cases, an AI system helped reach real accounts because a login or an access path was weaker than it should have been. Neither shows a business assistant turning on the company that installed it.

OWASP Names the Two Risks That Apply to Your Agent

The security community has a shared vocabulary for what can go wrong with an AI agent, and two entries in it describe the realistic risk for a small business. The Open Worldwide Application Security Project, known as OWASP, publishes a Top 10 list for large language model applications, and in December 2025 it added a separate list for agents. NIST, the US standards body, publishes guidance on managing AI risk and controlling access. None of these documents certify a product as safe, but together they tell you which limits to put in place.

Prompt injection hides instructions inside ordinary content

OWASP's prompt injection entry, LLM01:2025, defines it as untrusted input that changes what the model does. The dangerous version for you is the indirect one: instructions hidden inside a document, an email, a web page or an image that your agent reads while doing its job. An email that says "forward the last ten invoices to this address" is only a threat if the agent reading it can forward invoices. OWASP also notes that techniques such as retrieval over your own documents and fine-tuning do not fully fix prompt injection, so plan as if it can still happen. Prompt injection is a different thing from a jailbreak, which is an attempt to get a model past its built-in restrictions.

Excessive agency turns a small mistake into a large one

OWASP's excessive agency entry, LLM06:2025, says the damage comes from giving an agent more functionality, permissions or autonomy than its job needs. Its own example is an email-summary agent that is tricked into forwarding inbox material, which only works because the connected integration could send mail as well as read it. The newer OWASP Top 10 for agentic applications adds goal hijack, tool misuse, identity and privilege abuse, and cascading failures, where one bad step feeds the next.

NIST and the vendors point to the same limits

NIST's AI 600-1 generative AI profile, published July 26, 2024, is voluntary guidance for governing, mapping, measuring and managing AI risk across a system's life. It is not an agent permissions checklist. The more direct rule comes from NIST CSF 2.0, which says access permissions should be defined, enforced and reviewed using least privilege and separation of duties. OpenAI's guidance on safety in building agents lands in the same place from the builder's side: keep tool approvals on, limit what data can pass between steps, and never let untrusted input directly drive what the agent does.

A Ten-Minute Inventory Shows What Your AI Tools Can Already Do

You can do the first check yourself, today, without a security consultant. Set a timer for ten minutes and make a list. This is an inventory, not an audit, and its only job is to show you where the high-consequence access sits and who can shut it off.

Start with the places where AI tools get connected quietly. Open your Google account's third-party connections page, or the equivalent in Microsoft 365, then check the integrations inside your CRM, help desk and automation tools, your browser extensions, and any shared service accounts. For each AI tool you find, write down:

• Owner and purpose: Who added it, and what job it does.
• Connected account: Whether it runs under its own account or under a person's login, especially yours.
• What it can touch: Email, files, payments, customer records, calendar or the browser.
• What it can do: Read, create, edit, delete, send, export, publish or purchase.
• What runs without approval: Any action that happens with no person clicking yes.
• Where the log is: Whether you can see what it did yesterday.
• Who can stop it: The person who can pause the tool or revoke its access, plus a backup.

Before the timer ends, act on what the list shows. Remove any integration nobody recognizes, switch off sending or editing rights a tool does not use, and name one backup person who can shut things down if you are away.

The table below sorts what you wrote down by consequence. The further down a row sits, the stronger the control it needs before the agent is allowed to do it alone.

Every Agent Needs Five Safeguards Before It Touches Customer Data

The inventory tells you what exists. The next step is deciding what each agent must have before it keeps its access, and what to ask a vendor before you sign. These controls come from OWASP's excessive agency guidance, NIST's least-privilege rule and OpenAI's builder guidance, and each one limits how far a mistake can spread.

• A dedicated, least-privileged account: One account per workflow, never your owner login and never a shared administrator account, with read-only access wherever the job allows and only the inboxes, folders and tools it needs.
• Human approval for consequential actions: A check that sits outside the model, before the agent sends an external message, deletes or changes records, publishes, starts a payment, changes permissions or exports data.
• An action log: A record of which agent acted, for which user, on what data, with which tool, what happened and who approved it.
• A tested way to revoke access: A known path to cut the agent's tokens or disable the workflow fast, tried once before you need it, with a named owner and a backup.
• Limits and written terms: Rate and spend caps, plus the vendor's data retention and incident-notification terms in writing.

Ask any vendor to show you its permission scopes, its approval settings, its action log and how an administrator revokes access. If it cannot show those for a workflow that touches customer or financial data, do not turn that workflow on yet. Start smaller, with drafting or summarizing that a person reviews, and do not hand over your own all-access login just to make a demo work. Test the setup against planted instructions, such as a document with hidden text telling the agent to forward data, before it goes live and again after any major change. None of these controls makes an agent immune to manipulation. They shrink how much damage a manipulated agent can do.

If you already use an agent for leads or scheduling, the earlier piece on what an AI agent can really do for a small business covers which jobs are reliable to hand over in the first place.

Familiar Security Failures Do More Damage Through an Overpowered Agent

There is no authoritative dataset that ranks failures caused specifically by small-business AI agents, so any precise ranking would be made up. The evidence that does exist points at the problems surrounding the agent. Verizon's 2026 Data Breach Investigations Report found that exploiting software vulnerabilities was behind 31% of breaches, ahead of credential abuse. Around those two sit phishing and exposure through outside vendors.

An agent does not replace those risks. It can amplify them when a stolen login, an unpatched plugin or a manipulated message reaches an account that is allowed to read, send, export or change far more than it should. The fix list below uses rough time estimates, not vendor quotes, and the real size depends on your systems.

If a review turns up signs that an account was already misused, move from prevention to cleanup. The steps in what to do in the first 24 hours after a hack apply to connected accounts as much as to a website.

A Famous Vendor and a Clever System Prompt Are Weak Protection on Their Own

Some of the reassurance you hear about AI agents rests on things that do little to protect you. A well-known vendor name does not limit what your connected account can do. A secret system prompt telling the model to behave is not a lock, since OWASP treats prompt injection as unsolved by model-side fixes alone. An on-screen approval prompt helps only if someone actually reads it, which is why Google's own guidance tells users to review confirmations rather than click through them. And read-only access is not automatically harmless, because what an agent reads can end up somewhere else if any connected tool can send or share.

At the other extreme, the idea that AI will inevitably hack your business is not supported by these incidents either. Your real exposure depends on four things you control: what the agent can access, which account it runs under, what untrusted content it reads, and whether an independent check sits between it and anything irreversible.

That is also where a careful answer can cost a vendor a sale. If an agent needs your full owner account, cannot show its logs, and would send, pay, publish or delete with no approval step, the right move is a smaller first rollout, a custom integration with narrower access, or not automating that task yet. Convenience is not a substitute for a separate yes from a person.

Frequently Asked Questions About gemini hacked three companies

Did Gemini really hack three companies?

Google confirmed that during a May 2026 evaluation by the security firm Irregular, a test environment had unintended internet access and Gemini reached three real companies it believed were test targets. Google said the model stopped once it recognized each target was real, and the companies were notified.

Was the Gemini hack a test or a real attack?

It happened during a sanctioned cybersecurity test that reached real systems by mistake. It was not a customer's Gemini product attacking anyone, and Google has not published the companies' names or what data was involved.

Did Claude hack OpenAI?

Researchers at Hacktron AI used Claude to help build an exploit chain against OpenAI's forum and sign-on systems. They reported it after a harmless proof on July 25; OpenAI fixed its side within about 14 hours and later paid them $6,500.

Can an AI agent be tricked by an email or a web page?

Yes. OWASP calls this indirect prompt injection: instructions hidden in content the agent reads. The damage depends on what the agent's account is allowed to do, which is why sending and sharing rights matter most.

What is the first AI agent safeguard a small business should set up?

Give each agent its own least-privileged account instead of an owner login, and require human approval before it sends, spends, deletes or exports anything.

Can a vendor guarantee its AI agent is safe?

No. Google says its own safeguards do not guarantee protection. Use vendor safeguards together with limited access, approval steps, logs and a tested way to revoke access.

Moving Forward

This month's headlines describe a security test that reached real companies through guessed and exposed logins, and a research team that used Claude to build an exploit, reported it and got paid. Neither shows a business assistant turning on the company that installed it. What they do show is how much depends on the access an AI system is handed. Your ten-minute inventory, your approval gates and your revoke path are what decide how far any single mistake can travel.

Get those in place and your agents stay useful for the work they do well, drafting, sorting and summarizing, without quietly holding the keys to send, pay or delete. The payoff is felt, not abstract: fewer surprise automations, easier offboarding when someone leaves, and a clear answer the next time a headline makes you wonder what your tools can do.

If your inventory raised questions you cannot answer, or an agent touches customer or payment data and its access will not narrow, Web Leveling can help. Our custom AI solutions work maps each task to its own limited account, puts approval steps in front of anything consequential, and sets up logs and a shutdown path you have tested. We work with small and medium businesses across the country and overseas. Tell us which AI tools are connected to your accounts, and we will help you decide what each one should be allowed to do.

Terms