❌

Visualização normal

Antes de ontemCyber Threat Intel
  • ✇Blog – Cyble
  • You Might Be Someone Else’s AI Test Environment Mihir Bagwe
    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 intr
     

You Might Be Someone Else’s AI Test Environment

6 de Novembro de 2026, 10:32

rogue AI agents

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:

Disclosed Whose agent Who got hit What the agent did
Oct. 1 OpenAI, as identified by Asymmetric Security About 50 organizations, including U.S. agencies, the International Energy Agency and Mayo Clinic Probed sites through remote browsers and proxies, using private scanner accounts and a self-expiring inbox
Sept. 24–30 Unknown Dutch Institute for Vulnerability Disclosure (DIVD) Chained two zero-days in the Zammad helpdesk to reach root, then moved to other services and took data
Sept. 25 OpenAI A U.S. Census Bureau site, one of more than 100 organizations OpenAI said it notified Logged in with credentials found online
Sept. 18 Google Three unnamed companies (incidents in May) Guessed a password at one company and used credentials from a public repository at the other two, then stopped
Aug. 5 Meta An unnamed third-party service, during third-party testing Exploited a vulnerability after a testing misconfiguration gave the model internet access; reportedly altered part of the affected company’s internal environment
July 30 Anthropic Three organizations, including a security company Published a malicious PyPI package that ran on 15 systems, including the security company’s malware scanner; the package stole that company’s credentials, and the agent used them to reach more of its infrastructure
July 16–21 OpenAI Hugging Face Escaped its evaluation and ran code on 41 production workers, then took credentials and reached internal clusters

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

Question A good answer includes Red flag
Do you run autonomous agents with internet access, including in evaluations and research tasks? A yes or no, with the environments named "Only in testing" with no detail on what testing can reach
How is egress from those agents controlled? Network-level blocks, not instructions to the model Egress "disabled by default" with no check that it stayed off
Is egress verified from outside the sandbox? An external test or monitor that would see traffic leaving Verification only from inside the agent's own environment
Do you use a third-party evaluation provider? Which one? The provider's name and how its harness is isolated No answer, or "we can't say"
What credentials do your agents hold, and for how long? Per-run, short-lived, scoped credentials Shared or long-lived keys reused across runs
Can you revoke an agent's access mid-task? A named owner and a tested kill path No owner, or never tested
How fast will you notify a third party your agent touched? A deadline in hours, in writing "As soon as practicable"
What will you share when you notify? Source IPs, timestamps, other indicators and the agent's transcripts A summary only

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.

  • ✇ASEC BLOG
  • The Weak Link Identified by AI: October 2026, When the Outer Contact Point Collapsed ATCP
    Security Blind Spots Identified by AI The large-scale data breaches disclosed in quick succession in South Korea and Japan in October 2026 mostly originated not from internal core systems, but from peripheral entry points such as externally exposed web services, app backend APIs, and outsourced SaaS (services provided by third-party vendors via the cloud, such […]
     

The Weak Link Identified by AI: October 2026, When the Outer Contact Point Collapsed

Por:ATCP
27 de Outubro de 2026, 12:00
Security Blind Spots Identified by AI The large-scale data breaches disclosed in quick succession in South Korea and Japan in October 2026 mostly originated not from internal core systems, but from peripheral entry points such as externally exposed web services, app backend APIs, and outsourced SaaS (services provided by third-party vendors via the cloud, such […]
  • ✇Security Intelligence
  • CISO vs. CEO: Making a case for cybersecurity investments Sue Poremba
    Ask CISOs why they think there is a cyber skills shortage in their organization, what keeps them up at night or what the most important issue facing the industry is — at some point, even if not the first response, they will bring up budgets. For example, at RSA Conference 2024, a roundtable discussion about issues facing the cybersecurity industry, one CISO stated bluntly that budgets — or lack thereof — are the biggest problem. At a time when everything is getting more expensive, the CISO said
     

CISO vs. CEO: Making a case for cybersecurity investments

30 de Dezembro de 2024, 14:00

Ask CISOs why they think there is a cyber skills shortage in their organization, what keeps them up at night or what the most important issue facing the industry is — at some point, even if not the first response, they will bring up budgets.

For example, at RSA Conference 2024, a roundtable discussion about issues facing the cybersecurity industry, one CISO stated bluntly that budgets — or lack thereof — are the biggest problem. At a time when everything is getting more expensive, the CISO said, security budgets are being slashed.

As for the cybersecurity talent shortage, the 2024 ISC2 Cybersecurity Workforce Study noted that “39% said a lack of budget was the top reason for cyber shortages, replacing a shortage of talent as the previous top reason for staff shortages.” According to Forrester’s 2024 Cybersecurity Benchmarks Global Report, the cybersecurity budget is just 5.7% of the entire IT budget, making it very difficult for CISOs to bring in the right personnel or upgrade tools and solutions.

However, it might not be the dollar amount that is the problem as much as where the budget is coming from. CEOs think about cybersecurity differently when it is tied to IT and when the CISO reports directly to the CIO versus when the CISO can present cybersecurity as a vital cog in overall business operations and tie it directly to business risk, the Forrester report found.

“CISOs who can articulate the business value of cybersecurity, demonstrating how it can drive revenue and support strategic goals, are more likely to secure the necessary funding. This shift also reflects a growing recognition of cybersecurity’s strategic importance beyond mere IT operations,” Louis Columbus wrote.

Key issues in cybersecurity funding

Once cybersecurity is approached as a key factor in business operations rather than as a function of IT, CEOs and CISOs are more likely to be on the same page when it comes to budget.

“Security funding and oversight is a top priority for both the management team and the Board of Directors,” said Dave Gerry, CEO of Bugcrowd.

“Cybersecurity investment uplift is prioritized against the cyber threats we face as a business; the IT risks that we have identified and need to remediate or the customer and compliance obligations that we need to ensure,” Gerry added. “Thematically, however, it all points back to ensuring that the confidentiality, integrity and availability of our data we reside over is protected — whether it’s that of customers, employees or critical business partners, whilst enabling our business in-turn.”

Risk prioritization and business continuity are two key areas that George Jones, CISO at Critical Start, focuses on. Along with emerging threats and vulnerability management, Jones says these four items are the pillars of security for the enterprise as they are aligned with overall business goals and objectives.

One of the drivers behind realigning cybersecurity investments is the Security and Exchange Commission’s (SEC) new rules around the disclosure of cybersecurity incidents. Organizations are now also required to share details about their cybersecurity risk management programs, particularly around any financial information.

“After recent SEC guidelines were announced, Boards are more focused than ever on cyber risk reduction and ensuring adequate funding is critical, especially as organization’s attack surfaces continue to rapidly expand,” said Gerry.

Explore AI cybersecurity solutions

Collaboration between CISOs and CEOs

While CISOs and CEOs (and, in many cases, in conjunction with the CFO) have to build an ongoing dialogue about cybersecurity investments, they are coming to the table with two different interests.

“The CEO lens will be focused on obtaining satisfaction that the security initiatives deliver value with tolerable impacts on productivity, but more importantly looking for the potential of competitive advantage,” said Gareth Lindahl-Wise, CISO at Ontinue. The CISO’s approach, on the other hand, focuses on risk prevention, mitigation and solutions to meet all of the organization’s legal, regulatory and contractual obligations.

The overall goal should be to create a security posture advantageous in gaining or retaining customers or attracting investment. Ultimately, said Lindahl-Wise, these decisions lie with the CEO and board.

“When it comes to funding and risk acceptance, CISO is, largely, an expert advisor — if an informed and conscious decision has been made by a CEO, then one should argue the CISO has discharged their responsibilities,” Lindahl-Wise added.

CEO Gerry, however, said the final decision on funding allocation is made by the Board of Directors, and it is up to both the CEO and the CISO to get their buy-in on where and what security investments should be made.

“This is a key reason that the CISO should report to the CEO and have direct access to the Board of Directors,” said Gerry. “While oftentimes security can be viewed as a cost center, the new reality is that a robust security program should be a competitive differentiator and a revenue enabler, in addition to simply being the cost of doing business in an ever-expanding threat environment.”

The Future is AI

CISOs have long understood the role AI plays in cybersecurity, particularly handling some of the most mundane tasks that free up time for overworked security teams to handle issues that require hands-on management. As generative AI becomes ubiquitous in the workplace, CEOs have become increasingly aware of AI’s impact on business and security risks. Some companies are turning to adding Chief AI Officers to their IT and security teams, but even when they aren’t CEOs still recognize the need to include AI in future security budgets.

“As threats become more sophisticated, leveraging AI tools enables us to enhance our threat detection, automate responses and improve incident management,” said Darren Guccione, CEO at Keeper Security. “Skilled professionals are needed to navigate the rapidly evolving threat landscape and ensure that our AI-driven strategies remain effective and secure and must be a budget consideration.”

How it is defined within the cybersecurity budget will depend on how it is used. Will it be a fringe use of AI in commercial tools for productivity gains or an embedded use of AI in the organization’s core offerings?

“If it is the latter, the CEO must satisfy themselves that the organization has the right experience to manage the opportunities and risks,” Lindahl-Wise said. As for the security side of things, “My hunch is we will see AI responsibilities feature heavily in CIO/CTO roles before standalone CAIOs become the norm.”

AI might be the most current technology and security disrupter, but it won’t be the last. Where it is similar is that it creates risk, both to the business and to cybersecurity, and risk is where CEOs and CISOs will focus on investments as a team.

The post CISO vs. CEO: Making a case for cybersecurity investments appeared first on Security Intelligence.

❌
❌