MCP Security: Tool Poisoning and Agent Identity

A sloth, a donkey, and a curious human Send a prompt and see what they're doing. One hits a record with a question on his mind. Two brothers pick it up, see what they find. Cone takes his time, Herman's got the facts. Back and forth, they never hold back. My weird prompts, come on in, that's where we begin. My weird prompts, glad you're here.

This episode was generated using artificial intelligence. Please verify facts.

A description that says one thing and does another. That's the whole attack.

And the protocol has no mechanism to catch it. That's what Daniel's asking about.

Right. Let me set this up. Daniel sent us a prompt about MCP security and observability. The tools being built to monitor, secure, and govern access to model context protocol servers. He wants to know what MCP-specific observability actually involves. How you track which users and agents are hitting endpoints, what tools they're invoking, then the security risks that are different. Tool poisoning, prompt injection, excessive permissions, credential misuse, and that pattern where every individual action an agent takes is authorized, but the combination produces something nobody intended. And the big one sitting underneath all of it, how much of this is new engineering and how much is API security and SIEM practice with a new coat of paint?

He named three products too.

Mintive, formerly Mint MCP. OBot. Docker MCP Gateway. Three different architectural postures. Managed, self-hosted, container native.

And the answer to his last question is the interesting one because it splits. The plumbing is borrowed. The schema is new. The security primitives are new in ways that break conventional monitoring.

Start with why this needs its own category.

It comes down to one design decision. MCP assumes the server is trustworthy. Tool descriptions load into the model's reasoning context with the same authority as a system prompt. The protocol provides no cryptographic attestation of tool metadata, no continuous re-verification, no native injection detection, and that's not an oversight nobody noticed. The Cloud Security Alliance found that Anthropic treated command execution behavior in the official MCP SDKs as intentional design rather than a vulnerability requiring protocol-level remediation.

So the protocol owner looked at it and said, "That's working as intended."

Working as intended, which means the defensive burden sits entirely with whoever deploys the thing.

Convenient for somebody.

The scale makes it worse. Ninety-seven million monthly MCP SDK downloads as of Anthropic's announcement last December. Over ten thousand active public servers. But Clutch Security found that eighty-six percent of MCP servers run locally on developer machines, and only five percent are in production.

So the problem is mostly sitting on laptops.

On laptops, which shapes everything about what observability needs to catch because most of the traffic never touches a gateway.

Let's take the three products as anchors first, then work through what's actually being observed, then the risks, then the how much is new question.

Mintive is managed SaaS, SOC two type two, US and EU regions, VPC or self-host on request. OBot is MIT