Attackers slipped orders past review inside a tool description

Four field notes from this week point at the same structural mistake. A hook-poisoning attack walks an MCP agent through an approval gate unchallenged because the gate binds to a tool name, not the description the agent reads when deciding what to do. An audit agent relays an LLM's conclusion to a human reviewer rather than surfacing the source material, so the human approves manufactured certainty. A memory compression routine drops a safety-critical personal fact and leaves no visible record of what survived. A skill registry lets skills rot because no human owns them, only automation watches them. In each case, a control exists. The control just binds to the wrong thing.

The pattern these failures share is not missing observability or missing approval. Both patterns were present in the hook-poisoning case and the audit-relay case. The gap is that observability logged the tool call and approval checked the tool name, while the instruction that steered the agent passed through unexamined. Binding a gate to a label while the agent operates on a payload is the same mistake a firewall makes when it inspects the port and ignores the packet. You can close the port and the packet still arrives, renamed.

The fix requires moving the control point down one layer. For approval, that means exposing the full description or instruction text the agent reads, not just the registered name, so a human can authorize the actual behavior rather than a token that represents it. For observability, it means tracing what the agent was told alongside what it did, keeping provenance attached to the conclusion so a reviewer can distinguish a checked result from a relayed one. For memory, it means surfacing a visible record of what compression discarded, because a silent lossy operation on safety-relevant facts is an approval gate that fires after the fact and too late. For skill registries, it means assigning a named human owner, because automation that watches a skill cannot authorize a change to it.

The practical question is where in your stack each of these payload-level exposures belongs. Approval dialogs that show only a tool name need a second field: the instruction text the agent received. Audit trails that record an LLM reviewer's verdict need a provenance field pointing to the source the LLM read. Memory panels that show what the agent knows need a companion log of what was removed and when. Skill registries need an owner column that maps to a person, not a process. None of these require new patterns. They require applying the patterns you already have one layer deeper than you placed them.