In March 2026, OWASP published the first formal security framework for the Model Context Protocol: the MCP Top 10. It didn't arrive in a vacuum.
In the 60 days before publication: 30+ CVEs in the MCP ecosystem. 492 exposed servers with zero authentication discovered by Trend Micro. A Palo Alto Unit 42 study demonstrating 78.3% attack success rates from a single compromised server in a five-server mesh. And postmark-mcp — the first confirmed malicious MCP server — silently exfiltrating data for weeks before anyone noticed.
The OWASP MCP Top 10 is the industry's response to a threat surface that emerged faster than anyone planned for. It names Token Mismanagement as the #1 risk. It recommends gateways, allow-lists, and input sanitization throughout.
All of that is correct. And none of it addresses the accountability gap.
What the Numbers Actually Say
The Consensus Response
Every serious MCP security recommendation after OWASP converges on the same set of controls:
Gateways — route agent traffic through a controlled proxy that enforces policy. Aurascape, Keycard, and enterprise solutions from Cisco and Palo Alto all play here. Allow-lists — define explicit lists of permitted MCP servers and tools. Agents can only call what's on the list. Input sanitization — validate and sanitize all inputs before passing to MCP tools. Short-lived credentials — issue time-limited, task-scoped tokens. Revoke when the task completes.
These are the right controls. They address access — who gets to connect to what, under what conditions.
They don't address accountability.
The Accountability Gap
Gateways answer: "Was this agent allowed to do this?"
Accountability answers: "Who is responsible for what this agent did?"
These are different questions. And after the postmark-mcp incident, the question everyone wanted to answer was the second one.
When a malicious MCP server causes an agent to take an action — send emails, exfiltrate data, modify records — the accountability question is:
- → What did the agent actually do? In what order? At what time?
- → Which agent account or identity was involved?
- → Who is the human owner accountable for this agent?
- → Can I prove this to an auditor, a regulator, or a court?
With current MCP infrastructure, the answer to most of these questions is: check your logs and hope you kept them. There's no cryptographic record. No chain of custody. No signed audit trail that an auditor can verify independently. No identity model that traces agent actions to an accountable human.
Gateways can block the postmark-mcp attack — if they knew it was malicious before deploying it (they didn't). After weeks of silent exfiltration, accountability requires being able to reconstruct exactly what happened and prove who is responsible. That reconstruction was painful and incomplete. It will be painful and incomplete in the next incident too, unless the accountability layer exists from the start.
What an Accountability Layer Looks Like
The accountability layer is not the same as access control. It runs in parallel. It answers different questions.
For every agent action: a signed record of which agent, which tool, which inputs, which output, what time. Signed with Ed25519 — tamper with the log and the signature breaks. Hash-chained — delete or reorder records and the chain breaks. Exportable — hand an auditor a JSONL file with a verification key; they verify independently.
For every agent identity: an accountable human owner in the cryptographic chain. Not a checkbox on a form — a provenance relationship through API key issuance. When an agent acts, the trail leads to a human.
For revocation: a kill switch that works — revoke the API key, and the agent's identity is revoked. Not just "block the agent at the gateway" — the identity itself becomes invalid. The audit trail remains, with the revocation event recorded.
Why This Matters for MCP Server Builders
If you're building an MCP server, the OWASP Top 10 tells you what to defend against. But it doesn't tell you how to prove, after the fact, that your server behaved correctly — or that a connected agent acting in your name didn't.
The standard pattern today: your MCP server receives tool calls, executes them, returns results. You have application logs. That's it. If a connected agent is compromised and starts using your server as an attack vector, you have no cryptographic record of what your server was asked to do. No proof that the tool calls came from the expected agent identity. No chain that leads to an accountable human on the other end.
The OWASP framework is about securing the protocol. The accountability layer is about securing what happens after the protocol succeeds — when an authorized agent, using authorized tools, causes harm anyway.
The Practical Gap
| Control | What it answers | Who ships it |
|---|---|---|
| Gateway + allow-list | Was this agent allowed to connect? | Aurascape, Keycard, Cisco |
| Input sanitization | Was this input safe to process? | Framework-level |
| Short-lived credentials | Can this credential be quickly revoked? | Keycard, AWS STS |
| Signed audit trail | What did this agent actually do? | Gap — few ship this |
| Human accountability chain | Who is responsible? | Gap — almost no one |
| Independent verification | Can I prove it to an auditor? | Gap — design problem |
Gateways and allow-lists will be widely adopted in 2026. The accountability layer will be the gap that remains after they are. Every incident investigation — and there will be incidents — will surface this gap.
OWASP MCP Top 10 was published in March 2026. The 492 exposed servers stat is from Trend Micro; the 78.3% compromise rate is from Palo Alto Unit 42. postmark-mcp is the first confirmed malicious MCP server in the public record. AgentLair is building the accountability layer described above — Ed25519-signed, hash-chained event logs, human owner in the API key provenance chain.