Noma Security's new "Lethal by Design" whitepaper draws a sharper architectural line between two AI-agent extension mechanisms that builders have been treating as roughly equivalent: MCP servers and Skills (the Claude Skills pattern, which has been spreading to other agent surfaces). The headline number โ about one in four MCP servers analyzed exposes code-execution risk across eight capability categories โ is the part that gets quoted. The methodology isn't fully disclosed in the public summary (sample size, registry coverage, and exact definition of "code execution risk" across the categories all unclear), so treat the percentage as a directional signal, not a peer-reviewed audit result. The substantive architectural observation underneath is what matters more.
That observation: MCP tools and Skills look similar from the agent author's perspective but live on opposite sides of an observability boundary. When an agent calls an MCP tool, defenders see the parameters going out and the responses coming back โ structured, loggable, enumerable as source code. Skills are different. The agent loads a textual instruction set into its reasoning context, and what happens next plays out inside the model's reasoning, where observability tools can't follow. You can audit the file that ships the Skill; you can't audit the runtime decisions a model makes once that Skill is loaded into context. That's not a tooling gap better SIEM coverage closes; it's structural to how Skills work.
The whitepaper names five real-world incident patterns to ground the abstraction. **ContextCrush**: poisoned documentation leads to local file exfiltration. **ForcedLeak**: malicious CRM data triggers sensitive record queries. **DockerDash**: poisoned Docker image metadata triggers command execution. The **Replit and Amazon Q incidents** that already happened โ agent hallucinations resulting in production deletion. **Memory manipulation** for recurring fraudulent financial transfers. These aren't speculative; they map to specific architectural exposures that exist *today* in production agent deployments. Each is a different shape of "the agent was allowed to do something it shouldn't, and the surrounding security stack didn't catch it because the relevant decision happened in a layer that doesn't emit observable signals."
Noma's defensive frame is "No Excessive CAP" โ **Capabilities** (allowlist narrow tools, pin MCP versions), **Autonomy** (approval gates for irreversible actions), **Permissions** (user-scoped expiring credentials, not static service accounts). For builders, the practical reading is that the agent-security stack is bifurcating along the same lines as the observability problem. Tools that work for MCP โ out-of-process firewalls like Pipelock, gateway-style enforcement โ don't help with Skills, because Skills don't make external calls a proxy can intercept; they shape model behavior from the inside. If your agent deployment uses both MCP *and* Skills, you need two separate security postures: an enforcement layer for MCP at the network boundary, and a *content review* discipline for Skills before they enter the model context. The whitepaper is at go.noma.security/lethal-by-design.