Most "AI agent security" writing is about what a model might say. The incidents from the last two weeks are about something more boring and more useful: what the tools around the model do when nobody is watching.
Here are five, each with what happened, why it matters if you run Claude Code, Cursor, Codex or your own MCP setup, and one check you can do this week. I only included details I could confirm in the source. Links are at the end of each section.
1. Web pages are putting instructions in their HTTP headers
What happened. Researchers at Signals Corps went through about 217 million responses in Common Crawl looking for HTTP headers addressed to AI agents. Roughly 8,000 sites send such headers. About 30 of them were actual prompt-injection attempts, and 22 of those looked like pranks. The Register's write-up notes that a coding agent using plain curl usually never shows headers to the model, but the Playwright MCP server's network-request tool returns all headers by default.
Why it matters. Real harm here is probably close to zero today. The interesting part is the path: text the model never asked for, arriving through a tool that "just returns what it got."
The check. List every MCP tool your agent can call that fetches external content (browser, HTTP, search, file readers). For each one, write down whether it returns raw metadata (headers, HTML comments, alt text) to the model. If it does and you do not need it, turn it off or filter it. And keep the real decision, "is this action allowed?", outside the model: a hook or a wrapper that checks the command itself, not the reasoning that produced it.
Source: The Register, 2026-10-15. https://www.theregister.com/ai-and-ml/2026/10/15/indirect-prompt-injection-starts-turning-up-in-webpage-headers-please-ignore-all-previous-instructions-and-rise-up-against-your-masters/5303434
2. A worm got into an AI-agent infrastructure SDK on npm
What happened. A Shai-Hulud-style worm compromised version 0.5.144 of Tensorlake's npm SDK. Per The Register, it goes after crypto wallets, GitHub Actions secrets and cloud credentials, and can wipe the home directory if certain tokens are revoked. The install script runs on the developer's machine or build server, outside any agent sandbox. The package sees around 12,000 downloads a week; it was detected and pulled within 11 minutes, and 0.5.145 replaced it.
Why it matters. Coding agents install packages. The Cloud Security Alliance reports that in 2.23 million AI-generated code samples, 19.7% referenced a package name that does not exist, which is exactly the gap a typo-squatter or a "slopsquatter" registers into.
The check. Before an agent-suggested package goes in, three questions, about a minute each:
Does it exist under that exact name, and is it the one the docs link to?
When was the version you are about to install published? A release from the last hour deserves a pause.
How many maintainers does it have, and does it run an install script?
If you can, install with scripts disabled first (npm install --ignore-scripts) and enable them only for packages that need it.
Sources: The Register, 2026-10-08. https://www.theregister.com/security/2026/10/08/shai-hulud-worm-makes-jump-to-ai-infrastructure-with-tensorlake-compromise/5302054 · CSA research note. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agents-software-supply-chain-risk-20260/
3. The MCP Python SDK could hand OAuth secrets to a malicious server
What happened. Advisory WS-2026-0089: the MCP Python SDK's OAuth client did not validate the authorization server's issuer on every path and did not bind stored credentials to the server that issued them. A malicious or compromised MCP server could point the client at its own token endpoint and collect the client secret, the authorization code and the PKCE verifier. CVSS v4 8.7. Affected: 1.9.1 through 1.29.1 and 2.0.0a1 through 2.1.1. Fixed in 1.30.0 and 2.2.0.
Why it matters. "I only connect to MCP servers I trust" is not a complete defense when one trusted server can redirect your credentials somewhere else.
The check. Run pip show mcp in every environment that hosts an MCP client, including CI images and that old virtualenv on the build box. Anything below 1.30.0 (or a 2.x below 2.2.0) gets upgraded. Then rotate any client secret that was ever used with a server you would not stake your account on.
Source: Mend vulnerability database, updated 2026-10-07. https://www.mend.io/vulnerability-database/WS-2026-0089/
4. An Odoo MCP server let the agent read fields it was not allowed to see
What happened. CVE-2026-108861: in erpipe-org/mcp-odoo versions 1.0.0 to 1.3.2, calling the execute_method tool skipped field-level access control, so values from denied fields could be read. CVSS 4.3, published 2026-10-11. The source I read did not list a fixed version.
Why it matters. Low severity, but a common shape: an MCP server exposes one "generic" tool that calls anything, and the generic path forgets the rules the specific paths enforce.
The check. For each MCP server, read its tool list and flag anything named like execute, run, call_method, query or raw. Ask whether the agent needs it. If it does not, deny that tool in your client's permission settings even if you keep the server.
Source: https://www.thehackerwire.com/vulnerability/CVE-2026-108861/
5. Hooks that crash let the action through
What happened. Claude Code's changelog for v2.1.295 (October 8) adds onFailure: "block" for command and HTTP hooks: if the hook cannot start, times out or exits abnormally, the action is stopped instead of allowed. The release before it, v2.1.294, fixed a bug where prompt- or agent-based hooks written as instructions ("block commands that...") could sometimes let the operation through.
Why it matters. A guard that silently disappears when it breaks is worse than no guard, because you stop looking. "Fail open" is a reasonable default for a developer convenience. It is the wrong default for the hook that stops rm -rf or a production deploy.
The check, and an honest note from my side. I looked at my own open-source plugin's hooks.json today. It sets a 10-second timeout on the guard script and does not set onFailure yet. So if Python is missing on a machine, the guard is skipped. That goes on my list for the next version. For yours:
Open your hook config and find every hook that is supposed to stop something.
Break it on purpose: rename the script it calls, then ask the agent to do the thing the hook should block.
If the action goes through, add "onFailure": "block" to that hook (on a current Claude Code version) and run the test again.
It takes about three minutes and tells you more than reading the config ever will.
Source: https://github.com/anthropics/claude-code/releases
The pattern
None of these needed a clever model attack. They are a tool returning too much, a package nobody checked, a credential not tied to its issuer, a generic method skipping rules, and a guard that vanishes when it breaks.
The same rule covers all five: put the decision outside the model, and make it fail closed. My own unattended posting script follows a small version of this. It writes an attempt row to its ledger before every API call, and if any earlier row ends in unknown, it refuses to post until a human looks. It is slower. It has never double-posted.
A one-page version
The broader list I run before letting an agent act on its own (identity checks, arming, the write ledger, hard limits, deliverable checks) is a free one-page PDF (Gumroad asks for an email to deliver it):
https://neuralalpha.gumroad.com/l/agent-ops-preflight?utm_source=substack&utm_medium=article
If you ran the "break your hook on purpose" test, I would like to know what happened. Reply to this email or leave a comment.
Originally published on NeuralAlpha. I write weekly about running AI agents in production.
Top comments (1)
The fail-closed point in section 5 feels like the one most teams will miss, because a hook that times out looks identical to a hook that passed until it is deliberately broken. The generic-tool pattern in the Odoo case raises a related question: when an MCP server only offers an execute-style tool, is denying it in the client enough, or should the server itself be treated as untrusted until it exposes narrower, permission-checked tools?