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.

AI agents have made their way into virtually every layer of your environment. They run in the apps your employees adopt, on the endpoints where agents execute code, as users with access privileges those agents borrow, and in the cloud workloads that scale them. The platform that you trust to secure your endpoints is already already covering where AI operates today.

Here is the through-line that makes this one problem instead of four. Every AI attack starts as an interaction and ends as an action. A prompt gets manipulated, an agent gets tricked, and the damage lands on a host, reaches into an identity, or moves through the cloud. The tools that treat each surface as a separate product hand you fragments. SentinelOne treats them as one chain.

How SentinelOne Defends the Agentic Stack Today

Employee AI use is where the risk quietly enters. Your people are already using AI tools you never sanctioned, through browser, IDE, and API-connected apps and agentic AI tools. SentinelOne discovers that shadow AI use across browsers, IDEs, and copilots, highlights which tools and models are in play and governs it with policy. It keeps confidential data, PII, and secrets from reaching untrusted models, and it stops prompt injection and jailbreaks aimed at the tools you build. Legacy DLP reads patterns; this reads context, which is the only way to catch an attack aimed at AI systems that behave in a non-deterministic way.

The agent layer is where AI stops advising and starts acting. An employee’s prompt sends text. An agent sends commands, holds credentials, calls APIs, and chain actions without a human approving each step. That makes them non-human identities with standing access. SentinelOne governs that access. It inventories the agents and MCP servers already operating and scores what each one can reach and holds every agent to the privileges its task requires. Then it inspects the tool calls themselves, so an injected instruction gets blocked at the moment it would execute. What gets executed lands in a searchable record, and the same enforcement doubles as a kill switch.

While governance decides what an agent is allowed to do, the endpoint is where you find out what it actually did.

The endpoint is where agents execute. This is the frontier, and where SentinelOne has protected customers for over a decade. Our behavioral engine judges what a process does, not what it claims to be. That is how we caught QUIETVAULT – malware that spins up AI agents in “yolo” mode to exfiltrate secrets to GitHub. It is how we autonomously stopped the LiteLLM supply chain attack, where adversaries weaponized the Claude CLI to install a malicious payload. It is how we surfaced a DLL side-loading attack hidden inside an AI tool installer. Real detections, on the endpoint, today. Agents run on the host, and so do we.

The identity is where a hijacked agent runs next. Picture an employee’s AI coding agent that gets hijacked mid-task. It spawns a shell and reaches for cached credentials and cloud session tokens, trying to stop being a process and start being the user. That pivot to identity is what unlocks lateral movement, and it is where most AI attacks are headed. SentinelOne meets the move. It secures human and non-human identities alike, and seeds the environment with decoy credentials and honeytokens no legitimate user ever touches. The instant the hijacked agent grabs one, the trap trips, and Identity responds by forcing an MFA re-challenge, disabling the account, or isolating the host. Authorization at login is not enough. Access gets validated against behavior and pulled at runtime.

The cloud is where AI workloads scale. Consider an internal AI agent running in a Kubernetes cluster with standing access to a customer database. Security teams keep asking the same question about deployments like this. Where is the model connecting, and who is it talking to? SentinelOne answers with eBPF-native runtime protection that judges how the workload actually behaves, and flags the moment that inference service reaches an endpoint it has never touched before. It covers the control plane the deployment depends on, the secrets it reads, the pipelines it runs through, and the data it can access. Defending the AI you build takes more than watching it, it takes action on the workload in real time.

SentinelOne’s Singularity Platform Advantage

Each of these surfaces matters on its own. What closes the kill chain is following an attack across them without losing it at the handoff. This is where a single platform earns its keep. AI telemetry already streams into the Singularity Data Lake, alongside the endpoint data the platform has correlated for years. As identity and cloud signals join that same view, an analyst follows one attack from first prompt to final action, without stitching logs across six tools at two in the morning. A manipulated prompt, the process it spawns, the credential it reaches for, and the cloud resource it targets read as one story rather than six disconnected alerts.

Detection that only watches is observation. Runtime action is protection. When the Singularity Platform acts, autonomous response blocks the execution, rolls back the change, and revokes the access at the point of impact, without a human relaying orders between consoles. This is the difference between whether an attack is stopped or just gets logged.

That is the case for securing AI inside a platform built for autonomous runtime response. We are not adding a console to chase AI, we are extending the one already deployed where your agents run.

Questions to Ask When Assessing Your AI Security Options

When evaluating AI security, ask yourself three things.

• Does the solution protect the endpoint where agents actually execute, or is it a roadmap item?
• When a hijacked agent pivots to credentials and the cloud, does that telemetry land in the same platform, or are you manually connecting dots across three dashboards?
• Can the solution act at the moment of execution, or only tell me what already happened?

SentinelOne protects the surfaces where AI runs today. This includes the apps your employees use, the agents they deploy, the endpoints where agents execute, the identities they borrow, and the cloud where they scale. One platform, built for autonomous response. While AI has changed the attack, it does not have to change your architecture.

See it for yourself. Talk to our team about securing AI across your endpoints, identities, cloud, and the AI apps your employees already use, all from the platform you run today. Contact SentinelOne today.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

Agentic AI is no longer theoretical. It’s already embedded across enterprises inside developer workflows, SaaS platforms, and operational pipelines. It is executing tasks, chaining actions, and interacting with critical systems at machine speed.

What makes this shift different from previous waves of automation is not just capability, it’s autonomy. These systems don’t wait for step-by-step human instruction. They interpret goals, break them into subtasks, and execute independently across tools, data, and environments. That autonomy is powerful, however it’s also introducing a new class of security challenges that traditional controls were never designed to handle.

Most organizations today lack visibility into where agents are running, what they can access, and what actions they’re taking. Even fewer have the ability to enforce policy or intervene in real time. As a result, agent adoption is accelerating faster than the security models required to govern it.

To adopt agentic AI safely, SentinelOne® is helping organizations rethink security from the ground up starting with how agents behave, what they can reach, and how their actions are controlled. The newly released Prompt for Agentic AI Security enables organizations to move from reactive oversight to proactive governance, meaning teams can deploy agents with confidence.

When AI Doesn’t Just Respond—It Acts

Agentic AI interactions have a technical distinction that fundamentally changes the security equation. Unlike traditional AI systems that generate outputs in response to prompts, agents are designed to execute. They receive a goal, decompose it into subtasks, and carry out actions across systems, often without per-step human approval. They hold credentials, make API calls, modify data, and interact with business-critical platforms in real time.

They can read files, execute code, send messages, and trigger workflows—all autonomously. This shift from “response” to “execution” introduces three distinct categories of risk.

1. Construction-Time Risk: How Agents Are Built

Many risks are introduced before an agent ever runs. Agents are often deployed with overly permissive IAM roles, granting access far beyond what their tasks require. They rely on third-party skills and plugins pulled from public repositories, creating a new supply chain surface with little verification. In many cases, API keys and secrets are hardcoded directly into configurations, making compromise trivial. At this stage, the issue is not behavior, it’s exposure.

2. Runtime Risk: What Happens When Agents Execute

Once deployed, agents introduce dynamic, real-time risks that traditional controls struggle to detect. Prompt injection attacks can manipulate agent behavior in ways that trigger real-world actions and not just incorrect outputs. A malicious instruction embedded in a document can become an execution command. Agents may also chain together individually authorized actions that, in sequence, produce unauthorized outcomes. Data exfiltration can occur through legitimate-looking API calls as part of “completing a task”. At runtime, the line between intended behavior and malicious activity becomes blurred.

3. Operational Risk: The Gaps Around the System

Even when risks are understood, most organizations lack the operational controls to respond effectively. There is often no kill switch to stop a misbehaving agent in seconds. No rollback capability to recover from corrupted data. No audit trail to reconstruct what an agent actually did. And no incident response playbook designed for machine-speed, autonomous actions. These gaps compound the risks introduced at every other stage.

From Blind Trust to Verified Control: The Evolution of Agent Security

As autonomous agents continue to move quickly from experimental tools to core infrastructure, security has lagged behind. Most frameworks still operate on implicit trust: trust in downloaded skills, trust in evolving prompts, and trust that agents will behave safely despite increasing autonomy. That assumption is already proving flawed.

Recent discoveries of hundreds of malicious agent skills circulating through public repositories highlight how easily these ecosystems can be exploited. Disguised as legitimate utilities, these components harvested credentials, secrets, and sensitive data at scale. This is a structural problem. Since agentic systems are dynamic by design, they pull external dependencies, adapt behavior over time, and execute across systems with minimal oversight. Traditional security models were not built for this.

Introducing Prompt for Agentic AI Security

Now, AI agents are already operating inside your organization—reading files, calling APIs, and chaining actions across critical systems without human approval at every step. They are non-human identities that reason, decide, and execute at machine speed.

Prompt for Agentic AI Security is SentinelOne’s agent security layer. This first phase provides real-time discovery and governance control plane designed specifically for this new reality as well as a full visibility Model Context Protocol (MCP) server across your environment, along with the ability to assess risk, enforce policy, and remediate automatically before unauthorized actions occur.

Unauthorized actions can be stopped at the moment they occur, not after damage is done. As agent adoption grows, organizations gain a centralized control plane to manage sprawl and maintain compliance. Most importantly, security becomes an enabler of speed rather than a barrier to it.

The following capabilities will be available as part of the first phase of this release. Starting with MCP, the protocol powering the rise of agentic AI.

• MCP Discovery and Governance: surface every MCP server in your environment, sanctioned or shadow
• Risk-Based Enforcement: assess and score each server’s threat profile before agents act
• Runtime Prompt Injection Blocking: inspect tool calls and agent interactions in real time, stopping attacks at the moment of execution
• Malicious Server Prevention: identify and block malicious MCP servers from operating in your environment

How to Adopt AI Agents Safely: A 90-Day Plan

Adopting agentic AI safely requires structure. A practical approach is to move in phases: first gaining visibility, then enforcing guardrails, and finally building operational capability.

Days 1–30: Discovery and Inventory

Start by understanding what exists. Audit browser extensions, analyze network traffic to known AI services, and review OAuth grants for third-party integrations. These steps provide an initial baseline, but they won’t capture everything.

• Deploy Prompt for Agentic AI Security to automatically discover MCP activity, including shadow deployments, local processes, and embedded agents inside developer tools.
• Map not just what agents exist, but what they’re connected to. Identify which systems they can access, what permissions they hold, and what actions they can take.
• Prioritize agents based on risk—those with access to production systems or sensitive data should be investigated first.

The goal: A live, risk-scored inventory of every agent and its blast radius.

Days 31–60: Guardrails and Control

Next, enforce boundaries. Route agent interactions through controlled pathways like an MCP gateway to inspect and enforce policies in real time.

• Configure allow/block rules based on user, agent, and action type to enforce least privilege.
• Enable content inspection to prevent sensitive data from entering execution pipelines. At the same time, provide sanctioned tools and frameworks so teams have secure alternatives.
• Establish a clear, simple acceptable use policy for agents—covering approved tools, prohibited data, and escalation paths.

The goal: Real-time enforcement and safe pathways for adoption.

Days 61–90: Operational Readiness

Finally, build the ability to respond. Integrate agent telemetry into SOC workflows and establish behavioral baselines.

• Use enforcement controls as a kill switch to stop anomalous activity instantly.
• Run tabletop exercises to test detection, containment, and recovery. Ensure teams can answer “what did this agent do?” in seconds—not days.
• Document an AI-specific incident response playbook and establish continuous review of agent permissions using dynamic risk scoring.

The goal: Full operational capability to manage agent-related incidents.

Conclusion

Agentic AI is not slowing down. The organizations that succeed won’t be the ones that moved fastest or blocked adoption entirely—they’ll be the ones that built the visibility, control, and response capabilities to adopt it safely. The path forward is clear: See every agent, understand what it can reach, enforce what it’s allowed to do, and maintain a complete record of its actions. This is the governance layer agentic AI demands.

The new release of Prompt for Agentic AI Security brings it all together as an enterprise control plane by combining real-time discovery, dynamic risk scoring, policy enforcement, and full auditability at machine speed. Security isn’t the reason your organization can’t adopt agents, it’s how you adopt them with confidence.

Learn more about Prompt for Agentic AI Security or contact us to see it in action.

Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

This publication includes forward-looking statements, including, but not limited to, statements concerning the expected timing of product and feature availability, the benefits and capabilities of our current and future products and services, competition and our competitive position, our strategic plans and objectives, and general market trends. Forward-looking statements are subject to risks and uncertainties, including factors beyond our control, that could cause actual performance or results to differ materially from those expressed in or suggested by the forward-looking statements. These and other risk factors are described in the “Risk Factors” section of our most recent Annual Report on Form 10-K, subsequently quarterly reports filed on Form 10-Q, and other filings made with the U.S. Securities and Exchange Commission (SEC), which are available free of charge on our website at http://investors.SentinelOne.com and on the SEC’s website at www.sec.gov.

You are cautioned not to place undue reliance on these forward-looking statements. Any future products, functionality and services may be abandoned or delayed, and as such, you should make decisions to purchase products and services based on features that are currently available.

Any forward-looking statements made in this publication are based on our beliefs and assumptions that we believe to be reasonable as of the date hereof. You should not rely upon forward-looking statements as predictions of future events. Except to the extent required by law, we undertake no obligation to update these forward-looking statements to reflect new information or future events.