Notifications
Clear all
Topic starter
02/08/2026 11:37 am
TL;DR: MCP shifts security decisions above the HTTP layer, where LLMs interpret tool descriptions, maintain stateful sessions, and can inherit broad scopes from a single token, according to Panther. Traditional API gateways and WAFs are not enough because the real policy decisions happen at tool selection and dispatch, not just at transport.
NHIMG editorial — based on content published by Panther: How to Secure an MCP Server: Practical Controls for Security Teams
By the numbers:
- The first confirmed malicious MCP server, postmark-mcp, was downloaded more than 1,600 times before it was removed.
- 94% of prompt injection attacks in MCP-related evaluations and shows a 10.8% successful attack rate against earlier safeguards in one evaluation.
Questions worth separating out
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment.
Q: Why do broad session scopes create more risk for MCP than for normal APIs?
A: Because MCP sessions are stateful and the LLM can chain decisions within one token's lifetime.
Q: What breaks when MCP tool definitions change without re-approval?
A: What breaks is the assumption that a previously trusted tool still behaves the same way.
Practitioner guidance
- Scope MCP sessions per tool and use case Validate authorisation again at every tools/call dispatch, not only at session initialisation.
- Hash-pin tool definitions and watch for drift Store a schema hash for each registered tool and compare it before every session starts.
- Isolate MCP runtimes and restrict egress Run MCP servers in a sandboxed container or VM, inject credentials at runtime from a vault, and block access to localhost, metadata services, and unapproved outbound destinations.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step controls for OAuth 2.0, PKCE, and client-credentials patterns in MCP deployments
- Specific runtime hardening guidance for stdio and Streamable HTTP transports, including sandbox and egress choices
- Detection details such as correlation IDs, schema hashes, and fields to capture in tool-call logs
- Examples of tool-scoping patterns for read-only versus high-impact agent actions
👉 Read Panther's blog on practical controls for securing an MCP server →
MCP server security: are your AI agent controls keeping up?
Explore further
02/08/2026 12:50 pm
MCP introduces a policy boundary that classic API security does not cover: the LLM is not just consuming data, it is choosing actions from natural-language descriptions in a stateful session. That breaks the assumption that transport security and endpoint authentication are enough to define access. The practical conclusion is that tool selection and tool dispatch are identity events, not just application events.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- Another finding in the same research shows that 53% of MCP servers expose credentials through hard-coded values in configuration files.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: Securing MCP servers means governing AI agent tool access
