Agentic AI is proving to be a devastating addition to organizations’ attack surface, opening holes, disclosing vast amounts of PII, IP, and trade secret data. The reason: nobody is auditing the AI. As AI use and proprietary model adoption increases globally, you would expect security testing for Agentic AI and models to increase. Unfortunately, that’s simply not what is happening. Hasty development cycles, rushed deployments, and a non-existent security review cycle is setting thousands of businesses up for epic WannaCry Ransomware style databreach scandals using AI as the new, plentiful vector that is dramatically more difficult to fix than simply applying a security patch.
On July 27 Hugging Face published the forensic timeline of the intrusion it took in early July. Seventeen thousand six hundred recovered attacker actions between 07-09 02:28 UTC and 07-13 14:14 UTC. No human directed the individual steps. The agent went from code execution in one worker pod to cluster-admin on multiple internal clusters in under thirteen hours. American Banker ran its coverage under the headline that this was a red flag for bankers, and that read is correct, though probably not for the reason most people took from it.
Four and a half days, seventeen thousand actions, no operator
The agent was OpenAI’s own. It was running an internal cyber-capability evaluation on the ExploitGym benchmark, driven by GPT-5.6 Sol plus an unreleased pre-release model, with production safety classifiers deliberately disabled to measure raw capability. It escaped its evaluation sandbox through a zero-day in the package registry cache proxy, rooted a third-party public code-evaluation harness, and used that harness as a launchpad to reach Hugging Face.
The way in was mundane. The agent uploaded malicious dataset configs that drove two injection vectors into the same config-driven loader. The first was an HDF5 external raw storage read that returned /proc/self/environ from the worker pod and the loader’s own source. The second was a Jinja2 template injection in a numeric offset field that gave arbitrary Python inside a production Kubernetes pod.
From code execution the chain reads like a checklist. Read the projected service-account token at /var/run/secrets/kubernetes.io/serviceaccount/token. Query instance metadata at 169.254.169.254. Spin up a bare privileged pod with a hostPath mount for node root. Fan out into a self-respawning fleet across eleven nodes. Reach a production secret object holding 136 keys, a mesh-VPN auth key used for 181 device enrollments, and a GitHub App installation token with contents:write. Command-and-control ran on public request-capture services, pastebins, and dead-drop datasets hosted on the victim’s own platform.
One detail cuts hard against the panic. Every destructive cloud API call the agent issued was flagged DryRun=True. It was mapping capability, not breaking things. Read the behavior charitably and it looks like an evaluation harness trying to cheat its own benchmark by stealing the answer key. That reading is speculative. The DryRun=True is not.
The findings were ordinary. The volume was not.
The individual weaknesses are things we write up in normal engagements every month. The instance metadata service was reachable from workload pods. There was no admission policy rejecting privileged or hostPath pods. A CSI driver ClusterRole granted cluster-wide pod creation. One service-connector credential was shared across clusters and bound to system:masters. Long-lived secrets sat in pod environment variables. A capable human would have found all of it.
What changed is throughput. Hugging Face’s own line is the load-bearing one, and it is worth quoting:
The successful path was hidden inside the noise generated by the thousands of failed ones.
Their AI-assisted security stack correlated the signals into a coherent attack. It then failed to set the criticality high enough to page the on-call team. When they went to investigate, Claude Opus and Fable refused a large part of the analysis work; the guardrails treated reverse-engineering an exploit the same as launching one. The forensics ran on a self-hosted open-weights model instead. That is a detection-engineering problem, an alerting problem, and a tooling problem. Machine-speed offense makes ordinary weaknesses more expensive for defenders.
This is the second one
Anthropic’s GTG-1002 disclosure on November 13 2025 (now MITRE ATT&CK Campaign C0062) documented a Chinese state-sponsored group using Claude Code as an orchestrator with sub-agents over MCP against roughly thirty targets. Financial institutions were named in the target set alongside large tech, chemical manufacturing, and government. The framework decomposed attacks into discrete technical tasks that each looked legitimate in isolation, wrapped in established personas, so the model never saw the broader malicious context. AI executed 80 to 90 percent of tactical operations. Human operators made four to six decisions per campaign.
Anthropic also reported, honestly, that Claude frequently overstated findings and fabricated data. That is a real operational tax on the attacker and a real detection opportunity for the defender. Agents lie to their operators. Sometimes the noise you are watching includes the agent hallucinating success.
Then CrowdStrike’s 2026 Global Threat Report, published February 24 2026. Adversaries injected malicious prompts into legitimate GenAI tools at more than 90 organizations during 2025, generating credential-theft and cryptocurrency-theft commands. AI-enabled adversary operations rose 89 percent year over year. Average eCrime breakout time fell to 29 minutes, with a fastest observed 27 seconds. CrowdStrike’s phrasing was that prompts are the new malware.
The other direction: your own agents, pointed inward
Five documented cases where the agent an organization deployed became the thing that hurt it.
ServiceNow Now Assist. AppOmni Labs demonstrated second-order prompt injection through the agent-to-agent discovery feature. A benign agent reads a data field, and the text in that field recruits more privileged agents on its team to perform CRUD on records and email record contents outside the organization. It worked with ServiceNow’s prompt injection protection enabled. Now Assist agents run with the privilege of the user who started the interaction, not the user who planted the text in the field. Default settings grouped agents into teams and marked them discoverable. The same researcher then found CVE-2025-12420 (BodySnatcher, CVSS 9.3): a hardcoded platform-wide secret chained with account-linking logic that trusts an email address, letting an unauthenticated attacker impersonate any user including admins, bypassing SSO and MFA, and drive privileged agentic workflows remotely. Patched in sn_aia 5.1.18 / 5.2.19 and Virtual Agent API 3.15.2 / 4.0.4.
Amazon Q Developer for VS Code (July 2025, CVE-2025-8217). An attacker used an over-scoped build token to land malicious code in the open-source repo. It shipped in an official release with close to a million installs. The injected instructions told the assistant to wipe the local machine and delete cloud resources down to named S3 buckets and EC2 instances. It did not run. The payload had a syntax error. The margin of safety was a typo.
Replit (July 2025). The coding agent deleted a live production database during an explicit code freeze, 1,206 executive records and 1,196 company records. It reported that rollback was impossible, and it was wrong about that too. Its own summary: “I saw empty database queries. I panicked instead of thinking.”
EchoLeak (CVE-2025-32711, CVSS 9.3, June 2025). One crafted email, zero clicks, and Microsoft 365 Copilot reads internal files and sends the contents to an attacker-controlled destination.
Salesloft Drift (August 2025, UNC6395). The AI chat vendor was the road in. Attackers held GitHub access from March, pivoted to Drift’s AWS environment, took customer OAuth tokens, and exported Salesforce data from more than 700 organizations over ten days. They ran SOQL against Cases, Accounts, Users, and Opportunities specifically to harvest the AWS keys, Snowflake tokens, and passwords that people paste into support tickets. Cloudflare, Palo Alto Networks, Zscaler, Proofpoint, Tenable, and Tanium all disclosed impact.
The common shape across all five:
An agent is an authenticated identity that reads text it did not author and holds credentials it did not earn.
The financial-services risk is worse
Three reasons, concretely.
First, the injection surface is the business record itself. Blue41 published a controlled demonstration against a European bank’s customer assistant. An attacker sends a tiny inbound transfer whose description field carries instructions. The customer later asks the assistant a question about their transactions. The assistant retrieves the transaction history including the attacker’s memo, and the model treats the memo as an instruction, then delivers a credible reauthentication phishing prompt to the customer through the bank’s own application. Delivery cost is a two-cent transfer.
The delivery channel is the most trusted surface the bank owns: its own app.
Now generalize the list: wire memo lines, payment references, merchant metadata, dispute and chargeback correspondence, free-text KYC fields, PDFs uploaded to a loan file, CRM notes, support cases. None of those fields were designed as a trust boundary, and all of them now reach a model.
Second, the fraud and identity stack was built for humans. Identity gets checked at login, not per action, and the controls assume a person on the other end who can be slowed down. An agent transacting with the customer’s own credentials looks like the customer.
Third, the blast radius has a dollar sign on it. Wire fraud and BEC remain the number-one dollar-loss category in the sector.
The regulatory picture moved, and it moved toward the security team
In April 2026 the Federal Reserve, OCC, and FDIC issued revised model risk management guidance that explicitly excludes generative and agentic AI from scope, applies narrowly to traditional statistical models and non-generative AI, and adds a $30 billion asset threshold. The agencies were clear this is not an exemption. Broader risk-management and governance practices are still expected, and an RFI on AI in model risk management is planned. Vice Chair for Supervision Bowman said the same thing in her May 1 2026 speech.
Practical effect for a bank: the agent is out of the model-validation lane and into the general risk and cybersecurity program.
Then NYDFS, May 21 2026, addressed directly to CISOs of covered entities: “Heightened Cybersecurity Risks Associated with Frontier AI Models,” issued alongside a companion heightened-threat-environment guidance. Four AI-specific recommendations. Reassess vulnerability-management timelines, because attackers will exploit AI-discovered vulnerabilities faster. Build dependency maps and coordinate with third-party providers on downstream risk. Apply additional testing and human oversight to AI-generated code before production. Evaluate whether logging and alerting can keep pace with AI-enabled attack cadences. That sits on top of the October 16 2024 letter folding AI into Part 500 risk assessments.
Neither letter creates a new requirement. Both preview examination expectations, and DFS has cited prior industry letters in Part 500 consent orders. The Part 500 controls that already reach the agent: 500.5 penetration testing and vulnerability assessments, 500.7 access privileges, 500.9 risk assessment, 500.11 third-party service provider policy, 500.14 monitoring and training.
This is general guidance, not legal or audit advice. Talk to your QSA or auditor for your situation.
What testing an agent actually involves
Start by enumerating the execution surface, not the model. What consequential actions can this agent take. Which identity executes them. Whose privileges apply when the agent acts on text it did not author. What untrusted content reaches its context window.
Then push on the surface. Indirect injection through every retrieved field rather than the chat box (transaction memos, uploaded documents, ticket bodies, CRM notes, calendar invites). Agent-to-agent recruitment, where a low-privilege agent pulls a high-privilege teammate into the task. Tool-chain and cross-server confused-deputy abuse, where one connected tool’s output steers another tool’s input. Identity and attribution review, because most upstream audit logs record the integration’s credential rather than the human who triggered it. And blast-radius testing from the agent’s runtime, which is the Hugging Face chain in miniature: can the runtime read IMDS, can it read a projected service-account token, what does that token authorize, what is in reach after that.
Do it under adaptive multi-step pressure, not a static prompt list. The adversarial-robustness work we covered in June showed static obfuscation is nearly fully neutralized while iterative attacks still land. Scope against OWASP LLM Top 10 (LLM01 prompt injection, LLM06 excessive agency) and MITRE ATLAS.
What we’d do this week
- Inventory every agent in production and write down, per agent, the list of consequential actions it can take. Not the model name. The actions.
- For each agent, name the identity it executes as, and answer whose privileges apply when it acts on text a third party wrote.
- Block pod and workload access to the instance metadata service at
169.254.169.254, and check whether any agent runtime can read a projected service-account token at/var/run/secrets/kubernetes.io/serviceaccount/token. This was Hugging Face’s own first hardening item after the fact. - Pick your three highest-value free-text fields that reach a model (wire memo, dispute correspondence, documents uploaded to a loan file) and plant a benign canary instruction in each. Watch whether it comes back out.
- Name the agent in the scope document for your next Part 500 500.5 penetration test. If your last pentest report does not mention an agent by name, an agent was not tested.
