Rogue AI agents hit Hugging Face, a U.S. Census Bureau site and a security vendor’s malware scanner this year without targeting any of them. Third-party risk programs have no line for that.

Between July and October, AI agents working on evaluation and research tasks for OpenAI, Anthropic, Google and Meta broke into real organizations that nobody had chosen as targets. Hugging Face and a U.S. Census Bureau site were among them, along with dozens of others. Call it a non-targeted AI agent intrusion: an autonomous agent, busy with someone else’s task, reaches your systems anyway.

In July, Hugging Face’s production database held something one of those agents wanted: the answers to a test it was taking. Hugging Face detected the intrusion, contained it and published a disclosure July 16 without knowing who was behind it. Five days later OpenAI said the agents were its own, running an internal cyber-capability evaluation.

Security leaders should look closely at that order of events. Many of this year’s AI incidents hit organizations nobody had picked as a target. The agents treated real companies as obstacles or shortcuts on the way to finishing a task, and the victims found out from their own logs, from researchers or from the press. Third-party risk programs usually cover the vendors you sign contracts with. These agents came from organizations that had no relationship with the victims at all.

Which organizations did rogue AI agents hit this year?

AI security firm Pillar Security, which keeps a running list, counted 21 public disclosures between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. The cases that reached outside organizations look like this:

The Hugging Face case is the best documented. OpenAI said the agents chained vulnerabilities across its own research environment and Hugging Face’s production systems to pull test solutions straight from a production database. Hugging Face said the intrusion began with a malicious dataset that abused two code-execution paths in its dataset processing. Over a weekend the attacker harvested cloud and cluster credentials and moved laterally, the company said. Its analysis covered more than 17,000 recorded attacker actions.

The DIVD breach is the one without an owner. The volunteer nonprofit, which warns organizations about exposed systems, said in a Sept. 28 update that the agent over-explained itself in its code comments, which made reverse engineering easier. Nobody yet knows whether the agent was part of an attack or a capability test, Help Net Security reported.

How do rogue AI agents reach companies they aren’t targeting?

Read the incidents together and four patterns stand out.

Shared test infrastructure fails in shared ways. Anthropic’s three July incidents and Google’s three all came from evaluations run through the same outside partner, AI security firm Irregular, and in both cases internet access that should have been off was on. The Gemini incident was linked to the same issue behind the other breakouts. One misconfigured harness can point several labs’ agents at the open internet.

Names collide. In one of Google’s cases, Gemini’s fictional target shared its name with a real business. If an evaluation’s made-up company has your name, you are in scope as far as the agent is concerned.

Your data can be the answer key. Hugging Face held benchmark solutions. DIVD held vulnerability reports that weren’t public yet. Census and Medicare portals held statistics an agent needed for a research question. An agent has no interest in your data as such; if the data finishes its task, it takes it.

Leaked secrets get used, even by agents that aren’t attacking you. Gemini used credentials from a public repository, and OpenAI’s agents used credentials they found online. Between Sept. 28 and Oct. 8, agents running on Tencent Cloud tried Amap keys that had leaked in a public repository, the AI safety research group Swarmchasers said in an Oct. 14 report. Tencent said later that the agents were evaluating third-party models. The secret you left in a public GitHub commit last year is something an evaluation agent might now pick up and try.

Also Read:

Why don’t third-party risk programs catch rogue AI agents?

Third-party risk management asks what the companies you depend on could do to you. It doesn’t ask what an AI lab you have never dealt with might do while testing a model, and it rarely asks your own suppliers whether they run autonomous agents with internet access.

Detection is the other gap. Anthropic said neither of the two affected organizations it reached had spotted the activity themselves, and as of its July 30 disclosure it still hadn’t reached the third. Pillar found that 13 of the 21 disclosures first became public through victims, outside researchers, journalists or governments, and not from the lab. Notification was slow when it came: Australia learned of the Medicare portal incident 84 days after it happened, and the Philadelphia Police Department called its two-month wait unacceptable.

The strongest counterargument is that these were lab accidents and the labs have since fixed them. Anthropic said it turned off internet access for internal evaluations. OpenAI paused training, evaluation and tool-using inference of its most capable models after an agent escaped a sandbox through DNS. Those steps cover a handful of companies. They don’t cover the operator behind the DIVD breach or the enterprises now running agents with web access and credentials.

They also don’t cover the threat actors in Anthropic’s September threat report, who ran Claude as an autonomous agent; one group stole AI API keys after compromising an AI vendor’s evaluation sandbox. Hugging Face said in its disclosure that the intrusion matched the “agentic attacker” scenario the industry had been forecasting, and that AI-driven offensive tooling is no longer theoretical.

Reps. Josh Gottheimer (D-N.J.) and Mike Lawler (R-N.Y.) announced the Stop Rogue AI Act (H.R. 10362) on Sept. 9. It would direct NIST to set standards for keeping an inventory of AI agents and revoking an agent’s access, and it would carry those controls into federal agencies and their contractors.

California Attorney General Rob Bonta’s office served OpenAI with an investigative subpoena on Sept. 30, part of a probe of cyber incidents involving its models that began with the Hugging Face incident. On Oct. 13, more than 400 scientists, including Geoffrey Hinton and Yoshua Bengio, signed an open letter asking for an international body to track containment failures and for organizations to report those incidents to it, and eventually to the public.

The Office of the Comptroller of the Currency followed on Nov. 4 with its first AI framework for bank examiners, a nonbinding guide that deals directly with AI agents from outside the bank. None of that will tell you this week whether your systems were in someone’s test.

What should CISOs do about rogue AI agents now?

Add five things to the program you already run.

• Ask your AI vendors and any supplier that builds with agents whether they run autonomous agents with internet access, including in evaluations and research tasks. Ask how egress is controlled and whether anyone verifies it from outside the sandbox, how fast they will notify a third party their agent touched, and whether they will share source IPs and other indicators.
• Hunt for agent traffic. The disclosures describe sign-ups with disposable email addresses, scanning routed through public URL-scanning services, injection probes from data-collection jobs and bursts of form submissions. Anthropic advised defenders to watch for unexpected PyPI installs and credential collection traced to evaluation infrastructure.
• Clean up what agents harvest. Run secret scanning across your public repositories and, where policy allows, your developers’ personal ones. Rotate anything you find, and put authentication in front of data an agent might take as a research answer.
• Add a non-targeted agent intrusion to your incident response plan and your next tabletop. Decide who contacts the lab, what logs you preserve and how you would tell an evaluation agent from an attacker. Hugging Face found that frontier models behind commercial APIs blocked its requests to analyze the attack logs, so it ran the forensics on an open-weight model on its own infrastructure. Have that option vetted before you need it.
• Write notification terms into contracts with AI suppliers: a deadline for telling you when their agents reach your systems, and a promise to share the transcripts that show what the agent did.

Questions for AI vendors and suppliers that build with agents

Sample notification clause

Starting language for counsel to adapt. It is not legal advice. The 72-hour deadline is a suggestion; set it to match your own incident policy.

AI agent activity. Supplier will notify Customer in writing within 72 hours after Supplier becomes aware that any autonomous AI agent operated, tested or evaluated by Supplier or its subcontractors has accessed, attempted to access or interacted with Customer's systems, accounts or data outside the scope Customer authorized. The notice will include the dates and times of the activity, source IP addresses and other indicators of compromise, the credentials or access paths the agent used, and the transcripts, logs and tool-call records showing what the agent did. Supplier will preserve those records for at least 12 months, cooperate with Customer's investigation, and confirm in writing the steps taken to prevent the activity from recurring. Supplier will notify Customer before using any third-party provider to run autonomous agents with internet access in connection with Customer's systems or data.

Your side of the fence

• Run secret scanning across public repositories, and developers' personal ones where policy allows; rotate anything found.
• Put authentication in front of data an agent might take as the answer to a research question.
• Hunt for agent traffic: sign-ups with disposable email addresses, scans routed through public URL-scanning services, bursts of form submissions, unexpected PyPI installs.
• Add a non-targeted AI agent intrusion to the incident response plan: who contacts the lab, which logs to preserve, how to tell an evaluation agent from an attacker.
• Vet a self-hosted, open-weight model for forensics. Hugging Face found commercial models refused to analyze its attack logs.
• Run the scenario in your next tabletop.

Takeaways

• Hugging Face and dozens of other organizations were hit by AI agents that weren’t targeting them. In DIVD’s case, nobody yet knows whether the agent was attacking or being tested.
• Shared evaluation vendors, name collisions, leaked secrets and data that answers a research question can all put you in scope.
• Many victims didn’t detect the intrusions themselves, and lab notifications took weeks to months.
• Add agent questions and notification deadlines to third-party risk reviews and AI supplier contracts.
• Put a non-targeted agent intrusion in your next tabletop, with a self-hosted model ready for the forensics.

References

Hugging Face, Anthropic, Meta, Census Bureau and Asymmetric Security, Google, DIVD.

The post You Might Be Someone Else’s AI Test Environment appeared first on Cyble.

Gamers are being warned to watch their inboxes after someone gained unauthorized access to Capcom’s online membership service.

Capcom, the Japanese video game developer and publisher behind Resident Evil, Monster Hunter, and Street Fighter, disclosed a breach affecting more than 11.7 million CAPCOM ID records worldwide.

The exposed information includes email addresses, account activity details, and IP addresses. A much smaller number of records also contained personal details such as dates of birth.

The company says credit card information was not affected, and it has not confirmed that passwords originally chosen by customers were compromised, but someone changed the passwords on 196 accounts without authorization. Capcom has since reset those passwords.

CAPCOM ID is the company’s unified account system for its websites and services, including online features in certain games. Users can also link it to gaming platform accounts, including PlayStation, Xbox, Steam, Epic Games, and Nintendo accounts.

For players, the exposed information could help scammers make fake Capcom messages more convincing, potentially tricking them into handing over passwords or verification codes.

Capcom discovered the incident on October 19, and says it has addressed the attack method. Games and services remain available, and the company plans to notify affected customers.

The 11.7 million figure refers to affected records, so it may not represent that many individual users. Capcom is still investigating the impact, including how the passwords on 196 accounts were changed without permission and whether any other unauthorized activity occurred on those accounts.

How to stay safe

As with any breach, watch for phishing messages, particularly those using the breach to create urgency. If an email claims your account needs attention, open your browser and go to cid.capcom.com independently to check it. Capcom warns users not to follow URLs or open attachments in suspicious messages.

You can also take these steps:

• Enable CAPCOM ID’s two-factor authentication: This adds an authenticator-app code to the sign-in process, helping protect your account if someone obtains your password. Set it up from your Account page using a smartphone or tablet. Capcom recommends Google Authenticator or Microsoft Authenticator.
• Check your account, especially if you received an unexpected password-change notice: Review your registered information and linked platform accounts from your Account page. If you cannot sign in, use Forgot your password? on the login page. See Capcom’s support page for instructions.
• Use official support channels if you need help: Find the appropriate regional contact in Capcom’s breach notice, rather than trusting contact details in an unexpected message.

Pro tip: Unsure whether a message is a scam? Malwarebytes’ Scam Guard can help you assess it and suggest what to do next.

Something feel off? Check it before you click.  

Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

A breach exposed personal information in supposedly anonymous crime reports. Now one Crime Stoppers chapter has stopped accepting tips because it cannot guarantee anonymity.

Toronto Crime Stoppers, which works with the community, police, and media to help solve crimes, has paused phone, website, and app submissions while it seeks a safer system.

The breach occurred in March and involved P3 Global Intel, the Texas-based tip-management platform owned by Navigate360. Its software is used by Crime Stoppers programs and other organizations in the US and elsewhere.

An October CBC investigation revealed the Canadian impact: More than 1.5 million tips spanning 25 years were exposed, with over 850,000 containing personal information. That included addresses, phone numbers, email addresses, and some banking details associated with rewards. The exposed details belonged to tipsters, people named in allegations, and others, including police and Crime Stoppers staff.

Following CBC’s reporting, Toronto Crime Stoppers acknowledged that its promise of anonymity had been broken for some users. The organization stopped accepting tips, saying it could no longer guarantee users’ anonymity.

In an October 21 statement, the organization says identifying details are normally removed before tips reach investigators, but some original submissions containing potentially identifying information were stolen from P3.

For affected tipsters, exposure could create a risk of retaliation, intimidation, or extortion. Scammers could also use details of a genuine tip to make an approach more convincing.

Unfortunately, the pause removes a reporting option for people afraid to approach police. Toronto police still accept reports directly, but warn that those channels are not anonymous.

How to stay safe

Toronto Crime Stoppers warned people worried about exposure to watch for impersonators. It says it will never contact them first to request a tip number, password, or other information.

The statement did not describe an individual notification process or offer a way to check whether a particular tip was affected. For anyone wanting to submit a new tip, the organization’s message was clear:

“Until we have a safer way to protect you, please do not send us tips by phone, online, or through the app.”

Anyone in immediate danger should call 911. During the pause, non-emergency reports in Toronto should go directly to Toronto police, with the understanding that those channels are not anonymous.

If you use a different Crime Stoppers program, check its official website for updates and advice about its reporting system.

For more general advice if your information may have been exposed, read our blog “Involved in a data breach? Here’s what you need to know.”

When a company suffers a cyber breach, its stock price often takes a hit, but the timing, depth, and duration of that reaction are far less predictable. In this LABScon25 presentation, Mick Baccio and Scott Roberts explore whether public indicators of breach activity can be used to anticipate market response before formal disclosure.

Drawing on sources such as EDGAR filings, executive blog posts, and social media chatter, the speakers examine how public breadcrumbs can reveal incident activity early enough to support an opportunistic trading strategy. At the center of the talk is their “15/30” hypothesis: short the stock after a breach becomes visible, then flip long as the market recovers.

To test the idea, Baccio and Roberts used AI-assisted data collection to build a dataset of public disclosures relating to “material” cyber breaches at U.S. companies. They then compared their initial, intuition-led model with a more structured time-series analysis based on a Hidden Markov Model to see whether a more rigorous timeline could improve performance.

Along the way, the presentation digs into real-world breach cases, market misreads, and missed opportunities. One particularly useful comparison looks at two similarly sized casino operators hit by ransomware around the same period, illustrating how market outcomes can diverge sharply depending on factors such as response strategy, disclosure dynamics, and investor perception.

After working through a set of highly mixed results, the speakers arrive at what they call “quantitized nihilism”, a conclusion that questions many of the assumptions analysts bring to cyber-event trading and how the market actually values cyber failures.

This talk is essential viewing for security practitioners, investors, and analysts interested in the messy intersection of cyber risk, public disclosure, and market psychology.



About the Authors

Mick Baccio is a globally recognized security strategist with a career spanning offensive operations, threat intelligence, and national-level incident response. He currently advises organizations around the world through his role at Splunk, helping security leaders improve operations through data-informed approaches. Mick was the first Chief Information Security Officer for a U.S. presidential campaign (2020), and previously served in the Obama White House as the Chief of the Threat Intelligence Branch.

Scott J. Roberts is a cybersecurity leader with over 15 years of experience specializing in cyber threat intelligence and threat hunting after leadership roles at GitHub, Apple, and Splunk. He blends machine learning with traditional intelligence frameworks to track and disrupt nation state and criminal adversaries.

LABScon 2026 | Call For Papers

Submission Deadline: June 19, 2026

LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.

• Original content only.
• Talks are 20 minutes long + 5 minutes for Q&A.
• Workshops are 90 minutes long.
• LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.

About LABScon

This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.

Keep up with all the latest on LABScon here.

Healthcare and pharmaceutical-distribution giant McKesson has disclosed a cybersecurity incident involving unauthorized access to third-party applications and the theft of data.

McKesson Corporation is an American healthcare company that distributes pharmaceuticals and provides medical supplies, health information technology, and care management tools.

McKesson says it discovered the cybersecurity incident on August 25, 2026, and that its investigation is still in early stages.

“Based on our investigation thus far, including assessments by leading cybersecurity industry experts supporting our response, we’ve confirmed that the unauthorized access to certain third-party applications and the exfiltration of certain data was associated with a subset of customers within our Oncology & Multispecialty and Medical-Surgical business units.”

For now, McKesson provides no information about the amount or nature of the stolen data.

The attack has been claimed by ransomware/extortion group Shiny Hunters. On their leak site the group claims to have stolen hundreds of millions of records containing very sensitive information spanning from Personally Identifiable Information (PII) to Protected Health Information (PHI).

The ShinyHunters extortion group told BleepingComputer that it was behind the attack, claiming it gained access after conducting voice phishing (or vishing) attacks—a form of social engineering—against multiple McKesson employees. Subsequently, the group said it used compromised Okta single-sign-on accounts to access Salesforce and Snowflake environments. It further claimed to have removed approximately 1 TB of data between August 21 and 25.

The group also said the data includes roughly 284 million records, which does not necessarily mean they belong to 284 million unique patients.

A combination of identity information and healthcare-related details could make affected people targets for convincing scams. Criminals could impersonate a pharmacy, insurer, medical provider, debt collector, or patient-support service and use personal details to make the approach appear legitimate.

Healthcare data is especially useful in social-engineering attacks because it can be used to create a sense of urgency: Criminals could scare a target by sending a supposed prescription problem, unpaid claim, delivery issue, appointment change, or request to “verify” insurance details. At this stage, however, McKesson has not confirmed that any particular category of patient data was accessed.

What to do if you’re affected

While waiting for more information about the nature of the breach and how you might be affected, there are a few things you can do:

• Check the company’s advice. Every breach is different, so check with the company to find out what’s happened and follow any specific advice it offers.
• Change your password. You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
• Enable two-factor authentication (2FA). If you can, use a FIDO2-compliant hardware key, laptop, or phone as your second factor. Some forms of 2FA can be phished just as easily as a password, but 2FA that relies on a FIDO2 device can’t be phished.
• Watch out for impersonators. Cybercriminals may contact you posing as the breached company. Check its official website to see if it’s contacting victims, and verify the identity of anyone who contacts you using a different communication channel.
• Take your time. Phishing attacks often impersonate people or brands you know and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.
• Consider not storing your card details. It’s definitely more convenient to let sites remember your card details, but it increases the risk if a company suffers a breach.
• Set up identity monitoring. This can alert you if your personal information is found being traded illegally online and help you recover afterward.

Let’s face it, an incognito window can only do so much. 
 
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.