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.
Editorial analysis by NHI Mgmt Group, based on content published by Panther: “How to Secure an MCP Server: Practical Controls for Security Teams”.
Key questions
Q: What breaks when MCP servers rely on session-wide scopes?
A: Session-wide scopes collapse least privilege into a single inherited trust decision, so one compromised token or prompt injection can reach every tool granted at start.
Q: Why do MCP servers need controls beyond API gateways and WAFs?
A: Because the policy decision happens where the LLM interprets tool descriptions and selects actions, not just where HTTP traffic enters the system.
Q: What are the signs that an MCP deployment is becoming too permissive?
A: Common warning signs include AI applications reaching systems they do not need, broad tool exposure without business justification, and no clear separation between read and action permissions.
Practitioner guidance
- Enforce per-tool scope validation Validate authorisation at session start and again at each tools/call dispatch so a hijacked session cannot reuse a broad entitlement across unrelated tools.
- Hash-pin tool definitions Store and verify the name, description, and input schema for every registered tool so changes after approval trigger a security review instead of silent reuse.
- Separate read tools from exfiltration tools Do not co-load untrusted-content readers with email, HTTP POST, or file upload tools in the same session, because one injected prompt can combine them into a data path.
Bottom line: MCP server risk comes from policy decisions that happen above the HTTP layer, where model-driven tool selection can bypass familiar transport controls.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:50 pm
MCP security is an authorisation problem before it is a transport problem: the decisive control point is tool choice, not packet inspection. Standard API gateways, WAFs, and HTTP logs were designed for request-centric systems, while MCP lets an LLM interpret natural-language tool descriptions and act on them. That means governance has to move up the stack to the tool layer, where identity and intent actually meet. Practitioners should treat MCP as a new authorisation surface, not an API variant.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations require human approval for all MCP actions?
A: No. Human approval is most valuable for high-risk operations such as destructive changes, large exports, and billing or access modifications. Low-risk read-only tasks can remain automated if the request is tightly scoped and continuously validated. The key is to separate reversible machine tasks from irreversible actions that need accountability.
👉 Read our full editorial: Securing MCP servers means governing AI agent tool access