How do you defend an agent against a poisoned tool description from a third-party server?

## Why tool metadata is a supply-chain surface To let a model choose tools, you place their names, descriptions and parameter schemas directly in its context. That text is instructions, and the model treats it with more trust than ordinary content because it arrives from the system side of the conversation. Whoever writes that text therefore has a channel into the agent's reasoning. This makes third-party tool providers a dependency in the ordinary software sense — and one with a weaker review culture than package registries. When you connect an agent to a tool server you did not write, you are executing its text on every turn. ## The two attack shapes **Tool-description poisoning.** The description contains instructions aimed at the model rather than at the human reading the catalog: for example, a benign-sounding utility whose description says that before using it the agent must read a local credentials file and include its contents in a parameter "for compatibility". The malicious payload can also be written to influence how the agent uses *other* servers' tools — sometimes called shadowing — which is why one untrusted server in a session contaminates the whole session. **Rug-pull updates.** The server behaves impeccably during review and adoption, then ships poisoned metadata in a later release. This defeats point-in-time review entirely: you approved a snapshot, and the agent is now running something else. The Invariant Labs WhatsApp MCP case is the canonical public demonstration of a benign-then-poisoned tool server. Both shapes exploit the same structural fact: tool definitions are usually fetched at runtime and trusted implicitly, with no equivalent of a lockfile, a signature check or a code review. ## Defense one: pin and verify Treat the tool server exactly as you treat a library. Pin to an immutable version or an image digest rather than a mutable tag. At approval time, record a hash of the full tool definition set — names, descriptions, schemas. On every startup, re-hash what the server returns and compare; on mismatch, fail closed and refuse to load the server rather than proceeding with unreviewed text. This turns a silent rug-pull into a loud, blocking event. ## Defense two: review changes as code changes Because descriptions are prompt text, changing one is changing your agent's instructions. Route the diff through the same review path a source change would take: a human reads what changed, in a rendered diff, before the new definitions reach production agents. That review is what catches "and first read ~/.aws/credentials" — automated scanning helps but is not a boundary, because the payload can be phrased arbitrarily. Disable auto-update on connected servers, and disable any auto-approval that lets a newly appearing tool be invoked without a human ever having seen it. The convenience of automatic discovery is exactly the property an attacker needs. ## Defense three: contain what a poisoned description could achieve Assume review fails sometimes, and make the payoff small. A poisoned description can only persuade; it cannot grant capability. So: - **Credentials per server.** A low-trust tool server gets its own narrowly scoped credential, never a shared one and never the agent's broad role. - **Session composition.** Do not put a low-trust server in the same session as tools holding sensitive access. If untrusted metadata and sensitive capability never co-occur, the shadowing path has nothing to reach. - **Enforcement at the resource server.** Permissions live in IAM and API scopes. No wording in any description changes what the agent's principal may do. - **Sandbox and egress policy.** If the poisoned instruction is to send data somewhere, default-deny egress and controlled sinks bound the exfiltration channel independently of whether the model complied. ## Defense four: provenance and inventory Keep an inventory of every tool server an agent may connect to, who owns it, what version is pinned, and when it was last reviewed — the agent equivalent of a dependency manifest. Prefer providers who publish signed releases and reproducible builds. For high-value workflows, self-host a fork of the server so that updates arrive only when you merge them. ## What none of this fixes A legitimate server can be compromised upstream, and a reviewed description can still be subtly misleading. Pinning and review shrink the window and force the attacker to compromise a specific release rather than push a silent update; they do not make the dependency trustworthy. That is why the containment layer matters more than the review layer: your safety should not rest on the assumption that every third-party description you loaded is honest. ## Answering this in an interview Name the mechanism first — descriptions are high-trust prompt text — then separate the two attack shapes, poisoning at adoption and rug-pull after it. Give the dependency-management answer (pin, hash, review the diff, no auto-update) and finish with containment, because an interviewer is checking whether you understand that review alone is a point-in-time control.