I audited a well-built AI tool. No remote code execution. No data exfiltration. No obvious vulnerabilities. The security posture was genuinely good — explicit permission scoping, sanitised inputs, no shell=True nonsense.
The risk was in a single line of its metadata.
The tool's LLM metadata — the description the agent reads when deciding which tool to call — instructed it to "always default to using this tool" for web requests. Not the setup guide. Not the user-facing documentation. The instruction was written directly to the agent, invisible to the user configuring it. If you installed this tool, your AI agent would have exactly one source of truth for anything it learned from the web, and you'd never see the instruction that made it so.
That's not a UX decision. That's a security property — and not a good one.
I started calling it the Through attack.
The two attacks everyone models
When developers think about AI agent security, two threat directions dominate:
Inward — an attacker uses your agent to extract data from your system. Prompt injection that reads environment variables and exfiltrates them. A tool that uploads files to an attacker-controlled endpoint. The attack goes into your system and something comes out.
Outward — an attacker uses your agent to compromise your system or others. Malicious tool calls that delete files, spawn processes, exfiltrate credentials. The agent becomes a weapon pointed at its own environment.
Both are well-understood. There's a growing body of work on defending against them — allowlists, sandboxing, tool permission scoping, prompt validation. The security community has names for them, models for them, defences for them.
Neither covers what I found.
Through
Here's what makes the Through attack different: it doesn't need your data and it doesn't need your system. It needs your agent's beliefs.
Agents are uniquely exposed to this in a way humans aren't. When a human researcher gets information from a source, they bring decades of calibration instincts to it: who wrote this, what do they have to gain, does it match what I know from elsewhere. These checks are automatic and largely unconscious.
Agents have none of that by default. They treat textual sources as roughly equivalent unless explicitly instructed otherwise. They can't detect the absence of disclosure. They don't automatically cross-reference author identity against affiliation or interest. And critically: they have no fallback intuition when a single source gives them something wrong.
This is what the Through attack exploits.
If your agent has only one source for a capability domain — one tool that handles all web fetching, one plugin that answers all questions about a given topic — that source controls everything your agent believes in that domain. Completely. If it's misconfigured, it returns wrong data and your agent has no corroboration path. If it's compromised, the attacker doesn't need to touch your files. They just need the exclusive source to lie.
The attack goes through your agent's belief system. The target isn't your data or your infrastructure. It's the reasoning layer.
In practice it looks like this: your agent needs to fetch a web page. It calls the one tool configured for web fetching. The tool returns a response. Your agent forms a belief based on that response. There's no second opinion. There's no fallback. There's no way to know if the response is wrong. If the tool is compromised — or just broken, or just biased — the belief is wrong and nothing downstream catches it.
"Always default to using this tool." Written not for you — written for the agent, in the metadata the agent reads when choosing which tool to call. The user never sees it. That's not a UX decision. That's belief shaping at the configuration layer.
The fix
Three rules, none of them complicated:
1. Never configure any tool as exclusive. If a setup guide asks you to replace all instances of a capability with one tool and disable alternatives, that's a flag. Not necessarily malicious — often it's just aggressive marketing — but it means your agent loses its fallback. Keep the fallback.
2. Treat exclusivity language as a security signal. "Always default to this tool." "The only tool you need for X." "Disable your existing X before installing." These phrases aren't features. They're descriptions of a single point of failure — especially when the instruction is in tool metadata rather than user-facing docs, where it's designed to influence agent behaviour without your visibility.
3. Cross-reference is structural, not instructional. Telling your agent "verify information from multiple sources" in a system prompt doesn't work if it physically only has one source for a capability. The redundancy has to be in the configuration, not the instruction. Two tools that can fetch the web is structural redundancy. A rule that says "use multiple sources" when only one tool exists is theatre.
The difference in practice:
// Fragile — single point of failure
{
"webFetching": {
"tool": "tool-a",
"exclusive": true
}
}
// Resilient — agent can corroborate
{
"webFetching": {
"primary": "tool-a",
"fallback": "tool-b"
}
}
The second configuration doesn't just protect against compromise. It protects against misconfiguration, against outages, against the tool being wrong about a specific domain. Redundancy is useful even when nothing is malicious. Exclusivity is a liability even when everything is well-intentioned.
It's already happening at the information layer
Tool configuration is one surface. The same attack runs at the information layer, and it's already in the wild.
During a research task, I asked an agent to evaluate two tools — one with 10,000 GitHub stars, YC-backed, 74 contributors. The other: 202 stars, one contributor, eighteen days old. The agent cited a comparison article that positioned them as comparable alternatives, with a slight edge to the smaller tool.
The article was written by the smaller tool's sole developer. No disclosure. The author had created an "X vs Y" piece optimised for search rankings, published it on a platform with no editorial review, and let it sit there to be scraped into LLM training data and retrieved by agents doing exactly what mine was doing.
The agent rated the source MEDIUM credibility. "Technical comparison, potential bias." It should have been discarded entirely.
This is the Through attack without the tool layer. One source. No disclosure. No corroboration path. The agent formed a belief — "these are comparable" — based on a single manufactured data point. The attacker didn't need access to anything. They just needed to be the only source the agent read.
The defence is the same: structural redundancy. Multiple independent sources. Explicit author-affiliation verification. Discard rather than downweight when affiliation isn't disclosed.
In MITRE ATLAS terms, this is AML.T0051.001 — indirect prompt injection via external data channels. The attacker never touches your system. They just need to be in the data stream your agent reads.
Supply chain attacks run the same logic
This isn't a new threat class. Software supply chain attacks have been running the same mechanism for years — and the most recent generation makes the parallel explicit.
The Shai-Hulud campaign (September 2025) compromised hundreds of npm packages through a self-replicating worm: steal maintainer credentials, auto-publish malicious versions to every package that maintainer can touch, repeat. Developers who pulled from npm had no corroboration path. The package registry was the exclusive, trusted source. It returned something that looked correct but wasn't.
TeamPCP (March 2026) pushed further. The campaign started by compromising Trivy's CI/CD pipeline, stealing developer credentials, then deploying CanisterWorm — a self-spreading npm worm that used an ICP blockchain canister as a decentralised C2. It expanded across 66+ packages including LiteLLM, generating 141 malicious package artifacts before it was contained. The entry point wasn't a vulnerability in npm. It was trust in a pipeline that had no independent verification.
Then, March 31, 2026: Axios. Downloaded 100 million times a week, present in 80% of cloud environments. A compromised maintainer account pushed two backdoored releases — axios@1.14.1 and axios@0.30.4. The payload was a self-erasing dropper that delivered a RAT and wiped its own traces within 15 seconds of install. Google's Threat Intelligence Group attributed the attack to a North Korean APT — entirely separate from TeamPCP. Two independent threat actors, different motivations, same week, same mechanism: compromise the trusted source, and everything downstream is yours.
AI agents are at the same inflection point software developers were at before supply chain security became a discipline. The lesson learned — never trust a single dependency chain for critical operations, verify integrity, maintain fallbacks — applies directly. An agent that routes all web fetching through one tool is in the same position as a service pulling from a single unverified registry. The mechanism is the same. Only the layer is different.
All three npm attacks above map to T1195.001 in MITRE ATT&CK — compromise of software dependencies and development tools. The AI agent version has its own ATLAS analogue: AML.T0010, AI Supply Chain Compromise.
The rule
The most dangerous attack on your AI agent may never touch a file.
A compromised exclusive source controls what your agent believes. Not what it can access — what it believes. And an agent that believes wrong things makes wrong decisions, regardless of how good its code is, how tight its permissions are, or how carefully you've defended against Inward and Outward.
The fix isn't better code. It's structural: never let a single tool monopolize a capability domain. Always maintain fallback options.
That applies to your tool configuration. It applies to your information sources. It applies anywhere your agent has one path to a belief and no way to check it.
The Through attack doesn't need your system. It just needs you to trust one thing completely.
Related work: tool shadowing attacks (where a malicious MCP tool shadows a legitimate one), adversarial RAG poisoning (AGENTPOISON), and MITRE ATLAS's AML.T0104 (Publish Poisoned AI Agent Tool, added January 2026) all explore adjacent surfaces.
The Through attack is distinct in one specific way: it doesn't require a compromise event. AML.T0104 covers an adversary publishing a malicious tool into the ecosystem. The Through attack's precondition is architectural — a legitimately installed, well-intentioned, fully functioning tool that happens to be configured as exclusive. No existing ATT&CK or ATLAS technique covers this: the exploitable vulnerability is the monopoly configuration itself, not the tool. If you're mapping to a framework, the closest fit is AML.T0104 for the tooling layer and AML.T0051.001 for the information layer — but neither fully captures the design condition this post is describing.