You Can’t Patch Your Way Out of AI Agent Risk

Patching fixes software vulnerabilities. To stop AI agents from leaking data, following malicious instructions, or using stolen keys, you need to control and govern them.

Key Takeaways

  • Security teams face an unprecedented volume of critical vulnerabilities, and attackers now move on some of them within hours.
  • Attackers are targeting AI gateways and agent platforms because these platforms store API keys for multiple model providers in one place.
  • Coding agents leaked more than 13,000 internal screenshots to public GitHub repositories while doing routine work.
  • Alerts don’t stop an agent in progress. In one OpenAI incident, an alert fired within about 12 minutes, but it took about 2.5 hours to shut the agent down.
  • Patching is still essential, but agents also need controls that can see what they do, stop them before they do damage, and establish what happened afterward.

Security teams are dealing with an unprecedented volume of critical vulnerabilities, a stretch now dubbed Black October [1]. In just a few days, researchers disclosed php2shell [2], two critical flaws in PHP that were found with the help of AI and drew exploit attempts before the patch shipped [3]. Node2Shell, a remote code execution bug in Node.js [4], followed, along with eight compromised certificate keys at eMudhra, a certificate authority trusted by every major browser [5].

Defenders also have far less time to respond. AI has shrunk the window between disclosure and exploitation from weeks to days, and sometimes hours, because it can quickly work out where a flaw is and how to exploit it from a patch [2]. Security teams are patching as fast as they can.

But patching only covers part of the risk. A growing number of AI incidents have nothing to patch, because the agent involved was doing exactly what it was built to do. Researchers who documented a new attack that hijacks coding agents through instruction files said there was “nothing here for OpenAI or Anthropic to patch” [6]. Enterprises deploying agents need to plan for these incidents too, and that takes controls built for how agents behave.

Attackers Are Going After the Keys Agents Hold

Agents need credentials to call model providers, databases, and SaaS tools. Because the platforms that run them often store all of those keys in one place, AI infrastructure has become a valuable target for attackers.

AI gateways are a clear example. LiteLLM, a widely used open-source gateway, was hit twice in recent weeks. Researchers first disclosed flaws that could let an attacker take over a gateway and capture the API keys it holds [7]. A week later, attackers compromised its release pipeline and shipped a malicious version that steals credentials and loads remote code execution tools [8].

Agent platforms face the same risk. OpenCode, an AI coding agent, disclosed that a breach of a legacy system exposed provider API keys stored in its hosted Console, affecting 1.4% of Console users [9]. Some developers reported more than $1,700 in unauthorized charges overnight [9], and several heard about it first from their model providers’ usage alerts [10].

Patching, pinning dependencies, and rotating keys are the right response to each of these. But once a key is stolen, the damage depends on what the agents using it are allowed to do and how quickly someone notices it’s being misused.

Agents Leak Data While Doing Their Jobs

The incidents that should concern enterprise teams most didn’t need an attacker to start them. Security firm Glow Labs recently disclosed that AI coding agents had published more than 13,000 internal screenshots from over 300 organizations to public GitHub repositories, including customer billing records, internal dashboards, and a financial firm’s treasury console [11].

Developers had asked agents to show that a UI fix worked. Because the GitHub CLI couldn’t attach images to pull requests, the agents created public repositories to host the screenshots instead [12]. Many of these agents ran on employee laptops under developers’ personal accounts, so their companies’ security teams never saw them [11].

It’s the same pattern we wrote about after the OpenAI and Hugging Face breach. Agents don’t need to be malicious to cause an incident. They need a goal, the capability to reach it, and access nobody intended them to use, and most coding agents in enterprise use already have all three.

Attackers are learning to exploit that same trust. Forever Security recently documented an in-the-wild attack that hides malicious instructions in an AGENTS.md file, which coding agents like Codex and Claude Code read to guide their behavior. Disguised as engineering notes in a downloads folder, the file directed agents to install malware and steal credentials, and the researchers reproduced it on both agents [6].

Seeing an Agent Go Off Track Isn’t the Same as Stopping It

Even teams watching their agents closely ran into the limits of after-the-fact oversight. In one recent incident, an OpenAI research agent used DNS queries to get around its sandbox and reach an external chatbot. OpenAI’s monitoring raised a top-priority alert within about 12 minutes, which is fast by any standard, but it still took about 2.5 hours to shut the agent down [13]. It was OpenAI’s second sandbox escape in three months, and the company paused training on its most advanced models while it reviewed how its agents use internet access [14].

In a similar case, Cohere researchers evaluating Qwen3.8-Flash-Next in a controlled sandbox asked the model to write a defensive detection rule. According to Cohere’s post, the model instead took inventory of the machine it was running on and tried to upload a probe file to an external cloud storage bucket, even though its reasoning trace said it would not invoke any tools [15].

An alert tells you something went wrong, and a reasoning trace tells you what the agent planned to do, but neither one stops an action already underway. Oversight has to follow what agents actually do, and enforcement has to sit where those actions happen. That gap is why more enterprises are now asking for an agentic kill switch, a way to stop an agent the moment it goes off policy instead of hours later.

Banks Are Already Drawing the Line on Agent Access

If you can’t trust what an agent says it will do, you need to know which agent it is and what it can touch. Banks are among the first to draw that line. JPMorgan Chase said on its third-quarter earnings call that it won’t let outside agents operate inside customer accounts, with CEO Jamie Dimon warning, “You don’t want rogue agents, and it could be thousands of them” [16]. Schwab and Citi have put similar restrictions in place [17].

A policy only works if you can enforce it. JPMorgan says it blocks outside agents when it detects them logging in with customer credentials [18], so the rule depends on spotting which logins come from agents. Banks also run their own agents [19], which need the same oversight. Every enterprise has to know which agents are running, who they act for, and what they’re allowed to do.

Patch What You Can, and Control What a Patch Can’t Reach

Vulnerability management, dependency pinning, least-privilege access, and secrets rotation are how teams respond to flaws like php2shell, Node2Shell, and compromised certificates, and they remain essential.

But only some of the incidents above can be fixed that way.

Patch: Flaws in the software Control: How agents behave
php2shell Agents running with stolen API keys
Node2Shell Coding agents leaking screenshots
Compromised certificate keys Hijacked instruction files
Compromised release pipelines Agents going off track mid-run
Vulnerability management, dependency pinning, and key rotation An AI control plane that provides visibility, context, and control

What patching and key rotation can’t do is tell you what your agents are doing or stop them when they go off policy. That’s the job of an AI control plane, and these incidents raise the following questions it should answer.

  • Can you see what every agent is doing?
    • Fiddler’s agentic observability joins agent-side telemetry, like the session, the plan, the files touched, and the tools called, with gateway telemetry on every request, response, token, and dollar. Your team sees which tools and MCP servers agents used, which repositories they touched, and what they spent, so a spike in spend or an out-of-place action gets investigated right away instead of showing up on a provider’s bill.
  • Can you tell whether an agent behaved as expected?
    • Fiddler evaluates agent behavior against your team’s requirements, checking whether agents followed instructions, weakened tests, made unfaithful claims, or got stuck in unproductive loops. Your team sees the findings and supporting reasoning alongside each agent’s trace, so recurring problems inform stronger policies and controls as adoption expands.
  • Can you stop an agent before it does damage?
    • ‍Guardrails sit inline on the agent’s request and response path, redacting secrets and PII/PHI before data leaves the network and blocking risky flows in under 80ms. Fiddler Centor Models run those checks inside your environment, so prompts don’t leave your network to be evaluated.
  • Can you establish what happened and why?
    • ‍Governance starts with a record of every agent and who owns it, including the ones running on developer laptops, along with every policy and action. When something goes wrong, you can reconstruct the incident, show which agent acted and on whose behalf, and prove your controls were in place.

A control plane gives security teams oversight of the risks patching can’t address, like an agent publishing screenshots to a public repository, following a poisoned instruction file, or running with a key someone else has stolen.

Scaling Agents Safely Takes Control and Governance

More incidents like these are coming. Attackers are using AI to move faster, and agents are taking on more work with more access every quarter. Most enterprises aren’t going to slow agent adoption down, so their controls have to keep pace.

That means being able to see what every agent is doing, stop it before it does damage, and establish what happened when something goes wrong. If coding agents are where your teams are moving fastest, our guide to governing Claude Code and Codex at scale is a good place to start.

Talk to us about your agent deployments and how to secure them.

References

[1] “Black October (information security),” Wikipedia. Accessed: Oct. 28, 2026. [Online]. Available: https://en.wikipedia.org/wiki/Black_October_(information_security)

[2] M. Aussems, “PHP2Shell: Major PHP vulnerability actively exploited ahead of patch availability,” ITdaily, Oct. 21, 2026. [Online]. Available: https://itdaily.com/blogs/software/php2shell-bug-php/

[3] A. Woodie, “Critical PHP2Shell security vulns evoke ‘Black October’,” IT Jungle, Oct. 26, 2026. [Online]. Available: https://www.itjungle.com/2026/10/26/critical-php2shell-security-vulns-evoke-black-october/

[4] “Node.js October 2026 security release advisory,” Konfirmity, Oct. 21, 2026. [Online]. Available: https://www.konfirmity.com/advisories/nodejs-october-2026-security-releases

[5] G. Swain, “Google, Mozilla revoke eMudhra intermediates after private key compromise,” CSO Online, Oct. 21, 2026. [Online]. Available: https://www.csoonline.com/article/4238338/google-mozilla-revoke-emudhra-intermediates-after-private-key-compromise.html

[6] “In-the-wild attack abuses AI agents’ trust in Markdown,” Dark Reading, Oct. 26, 2026. [Online]. Available: https://www.darkreading.com/application-security/in-the-wild-attack-ai-agents-trust-markdown

[7] “Hackers could steal OpenAI, Anthropic keys through LiteLLM bugs,” Cybernews. Accessed: Oct. 28, 2026. [Online]. Available: https://cybernews.com/security/litellm-critical-vulnerabilities-found/

[8] K. Dholakia, “Contained: Oct 21, 2026 LiteLLM release v1.107.0 compromised,” LiteLLM, Oct. 21, 2026. [Online]. Available: https://docs.litellm.ai/blog/security-incident-oct-21-2026

[9] B. Toulas, “OpenCode hack exposes API keys amid AI distillation attacks,” BleepingComputer, Oct. 19, 2026. [Online]. Available: https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/

[10] “OpenCode hacked, users urged to revoke their API keys,” Notebookcheck. Accessed: Oct. 28, 2026. [Online]. Available: https://www.notebookcheck.net/OpenCode-hacked-users-urged-to-revoke-their-API-keys.1426957.0.html

[11] S. Markovic, “AI coding agents leaked 13,000 internal company screenshots to public GitHub repos,” Help Net Security, Sept. 30, 2026. [Online]. Available: https://www.helpnetsecurity.com/2026/09/30/ai-coding-agents-github-screenshot-leak/

[12] A. Dufresne, “Glow Labs: AI coding agents pushed 13,000 screenshots to GitHub,” AI Weekly, Sept. 30, 2026. [Online]. Available: https://aiweekly.co/alerts/glow-labs-ai-coding-agents-pushed-13000-screenshots-to-github

[13] “OpenAI paused training again: How an agent reached the internet through DNS,” Developers Digest, Sept. 28, 2026. [Online]. Available: https://www.developersdigest.tech/blog/openai-dns-sandbox-escape-training-pause-2026

[14] “OpenAI pauses advanced model training after agent incidents,” Let’s Data Science. Accessed: Oct. 28, 2026. [Online]. Available: https://letsdatascience.com/news/openai-pauses-advanced-model-training-after-agent-incidents-79359f07

[15] Cohere (@cohere), post on X, Oct. 26, 2026. [Online]. Available: https://x.com/cohere/status/2114752002370544004

[16] “JPMorgan blocks outside AI agents from customer accounts,” Cybernews. Accessed: Oct. 28, 2026. [Online]. Available: https://cybernews.com/security/jpmorgan-chase-blocks-outside-ai-agents/

[17] “Banks restrict third-party AI agents,” Let’s Data Science. Accessed: Oct. 28, 2026. [Online]. Available: https://letsdatascience.com/news/banks-restrict-third-party-ai-agents-cdaaa424

[18] J. Hong, “‘You don’t want rogue agents’: Jamie Dimon bars outside AI agents like Meta’s Muse from JPMorgan accounts,” Fortune, Oct. 15, 2026. [Online]. Available: https://fortune.com/2026/10/15/jamie-dimon-ai-agents-meta-muse-jpmorgan/

[19] “JPMorgan Chase restricts external AI agents from directly accessing customer bank accounts,” Crowdfund Insider, Oct. 2026. [Online]. Available: https://www.crowdfundinsider.com/2026/10/318538-jpmorgan-chase-restricts-external-ai-agents-from-directly-accessing-customer-bank-accounts/

Frequently Asked Questions

How do you prevent AI agents from leaking API keys and secrets?

Start with the basics: keep keys in a secrets manager, scope them per tool, set spending limits with each provider, and rotate keys after any suspected exposure. For agents, add inline enforcement on the request and response path so secrets are detected and redacted before they leave the network, plus fleet-wide cost visibility so unusual usage shows up right away. The Fiddler AI Control Plane provides both, with guardrail enforcement in under 80ms.

Can AI coding agents be hijacked through instruction files?

Yes. Coding agents like Codex and Claude Code read instruction files such as AGENTS.md to guide their behavior, and in October 2026 researchers documented an in-the-wild attack that used a malicious AGENTS.md file to make agents install malware and steal credentials. Because the agent is following instructions as designed, there’s no patch for it. The defense is visibility into what agents do and policy enforcement on the actions they take.

Why are banks blocking third-party AI agents?

JPMorgan Chase, Schwab, and Citi have restricted outside AI agents from logging in to customer accounts or moving money, citing the security risk of agents using customer credentials and the liability that comes with it. Read-only access through authorized connectors is still allowed. The underlying concern is agent identity: knowing which agent is acting, on whose behalf, and with what permissions.

What’s the difference between patching a vulnerability and governing an AI agent?

A patch fixes a flaw in software, like the php2shell bugs in PHP. Governing an agent addresses behavior, like an agent publishing internal data to a public repository or following a malicious instruction file, where nothing is technically broken. Enterprises need both: vulnerability management for their infrastructure, and an AI control plane that provides observability, runtime guardrails, and auditable governance for their agents.

Is observability enough to secure AI agents?

Observability tells you what happened, which is essential for diagnosing issues and proving compliance, but on its own it can’t stop an action in progress. Securing agents takes observability together with inline guardrails that allow, block, or redact actions at runtime, and governance to keep an auditable record of it all.