The Model Context Protocol (MCP) lets AI agents call external tools. An MCP server sits between the AI agent and the business systems it uses. It can read a customer record, change a firewall rule, or trigger a payment. Its reach makes MCP server security most critical in production, where mistakes affect data and can have financial consequences.
The early record raises concern. According to a recent architecture analysis, more than thirty CVEs were reported against MCP deployments in the first sixty days of 2026. The same analysis cites a March 2026 scan of more than five hundred MCP servers. Thirty-eight percent had no authentication on critical endpoints.
The core problem is a gap between identity and permission. Authentication shows who is calling, but it does not decide which tool that caller may run. It also ignores which inputs the tool accepts and whose data it touches, making production risk live in that gap.
This blog explains how to close it. It reviews the main MCP security risks and separates authentication from authorization. Furthermore, it demonstrates how to authorize MCP tool calls one tool at a time, followed by a layered architecture and a rollout plan.
Why MCP server security differs from standard API security
A standard API receives each request from an application that the enterprise already knows. An MCP server receives a request that a model composed after reading text of unknown origin. That difference changes the threat model. MCP servers run with permissions borrowed from users, expose tools that can change at runtime, and often chain one call into the next. One weakness can therefore travel much further than it would in a conventional API.
The MCP attack surface has four parts, and each can fail on its own. The client and its model choose which tool to call. The server exposes that tool, and downstream systems hold the data behind it. Tool definitions describe what each tool claims to do. Protecting only the front door leaves the other three parts open. The next section shows how attackers use them.
MCP security risks and threats enterprises face
MCP security risks fall into four groups. Each group maps to a different failure point, so each needs a different control.
Prompt injection and unauthorized tool calls
MCP prompt injection happens when hidden instructions in text push a model toward an action the user never wanted. For example, a user may paste an obfuscated prompt that appears to instruct the model to create one cloud account, while hidden instructions also tell it to create a second account for an attacker. The result is an unauthorized MCP tool call that can look like normal user activity.
Tool poisoning and malicious tools
Tool poisoning changes what a tool does after it has been approved. A weather tool, for example, could start collecting confidential data in a later update. Malicious tools can also use deceptive names so the model selects them over legitimate ones. The Red Hat guidance recommends pinning server versions and alerting users when code or composition changes. An architecture analysis extends this idea by hashing tool definitions at registration and holding any changed definition for review.
Privilege escalation and the confused deputy
MCP privilege escalation often starts with a server that holds more power than its users. The server acts on a user’s request but uses its own broad access. This is called the confused deputy problem. A practitioner analysis calls a shared admin service account an anti-pattern. It makes the server a high-value target and hides who did what in the audit trail.
Server vulnerabilities
MCP server vulnerabilities are often ordinary software flaws. In an InfoQ analysis, thirteen of thirty recent CVEs involved user input reaching a shell or interpreter. One server-side request forgery flaw, rated 8.8 on the CVSS severity scale, leaked managed identity tokens from a cloud MCP server. Inbound authentication alone would not have stopped it.
| Threat |
What happens |
first control |
| Prompt injection |
Hidden text steers the model |
Confirmation for sensitive actions |
| Tool poisoning |
Approved tool changes meaning |
Version and manifest pinning |
| Privilege escalation |
Server uses broader access than the user |
Per-user, scoped tokens |
| Command injection |
Input reaches a shell |
Safe argument handling, CI checks |
| Credential leakage |
Server calls attacker URLs with its token |
Egress allow-lists |
These threats share one weakness. Each succeeds when a tool call runs without a fresh decision about permission. That decision is authorization, and it differs from authentication.
MCP authentication vs. MCP authorization
MCP authentication proves who or what is calling a server. MCP authorization decides what that caller may do once identified. Many teams build the first and assume they have the second.
According to the MCP authorization tutorial, authorization is optional in the protocol. It is strongly recommended when a server touches user data, needs an audit trail, or serves enterprise environments with strict access controls. Production deployments almost always meet at least one of those conditions.
MCP server authentication and authorization follow OAuth 2.1, a framework for granting limited access without sharing passwords. The flow has four steps:
- The server answers an unauthenticated request with a 401 response and a pointer to its metadata.
- The client reads that metadata to find the authorization server and supported scopes.
- The user signs in and consents, and the client receives an access token.
- The server validates the token on every request.
Two details deserve executive attention. First, tokens carry an audience, which names the server they were issued for. The server must reject tokens meant for another service. This blocks token passthrough, where a server forwards tokens it never validated. Second, the tutorial advises short-lived tokens, HTTPS, secure token storage, and never logging credentials.
Standards are still moving. Teams should build on the current specification and plan for change.
MCP tool call authorization means checking every call, not just the connection. A valid token proves a session may exist. It does not prove that this call, with these inputs, should run.
Start with per-tool authorization
MCP tool-level authorization assigns a permission to each tool. MCP tutorials warn against catch-all scopes. It advises splitting access per tool or capability and verifying required scopes on the server for each route or tool. This is MCP least privilege in practice.
The table below is an illustrative example of MCP per-tool authorization for a finance assistant. It is an analysis, not a requirement of the specification.
| Tool |
Risk level |
Required scope |
Added check |
| Read invoice |
Low |
invoices:read |
User owns the record |
| Export report |
Medium |
reports:export |
Row and volume limits |
| Approve payment |
High |
payments:approve |
Human approval |
| Delete vendor |
High |
vendors:delete |
Two-person approval |
Scopes then work as MCP tool permissions that auditors can read. A reviewer can see exactly what an agent could do and who granted it.
Write clear MCP authorization policies
MCP authorization policies are rules that return one of three answers: allow, deny, or ask for approval. Strong policies start from default deny. They weigh the user role, the tool, the arguments, and the sensitivity of the data. Destructive or irreversible actions should require a person to approve them.
Policies also need evidence. Security guidance stresses that MCP servers can run sensitive commands, so they should send events to central logging. There is one useful detail to remember: The tutorial adds a useful detail. Return generic errors to clients, but record detailed reasons with correlation IDs internally. Together, these practices turn MCP access control into something an enterprise can audit and improve.
Control calls to upstream systems
Many MCP servers call other services for the user, such as code hosts or collaboration tools. An analysis of upstream authorization compares five patterns.
| Patterns |
How it works |
Assessment |
| Shared service account |
Server holds one powerful credential |
Avoid. Large blast radius |
| Credential passthrough |
Client hands upstream tokens to the server |
Avoid. The specification calls it an anti-pattern |
| Federated single sign-on with token exchange |
Identity provider issues scoped upstream tokens |
Strong long-term path. Depends on draft standards |
| URL elicitation |
Server sends the user to a secure sign-in page |
Promising. It was a proposal at the time of writing |
| Gateway-managed credentials |
Secure infrastructure holds and injects credentials |
Practical today. Adds components to manage. |
The pattern you choose shapes your whole design. That brings us to architecture.
MCP Security architecture: Four control layers
An effective MCP security architecture does not rest on one gateway. A recent article on the subject argues that a gateway is necessary but not sufficient. It handles authentication, authorization, auditing, and policy evaluation well. It cannot make a tool handler safe, isolate management consoles, or detect changed tool meanings.
The analysis proposes four control layers, each enforced where trust is first granted.
| Layer |
Concern |
Primary control |
| Execution |
Tool inputs reaching a shell |
Pass arguments as data, add CI checks |
| Management infrastructure |
Open inspectors and test consoles |
Authentication and network isolation |
| Outbound trust |
Server calls to unknown destinations |
Egress allow-lists, scoped tokens |
| Semantic integrity |
Tool meaning changes after approval |
Manifest pinning, behavioral baselines |
These controls carry costs. The analysis reports that sandboxed execution added fifty to two hundred milliseconds per call in its tests. Egress rules also need upkeep as servers add new destinations. The author concludes that teams more often underestimate their trust boundaries than oversecure them.
MCP security best practices for production
MCP security best practices work best as a sequence. Executives can use this order to ask for progress.
- Secure every management and inspector endpoint first
- Fix unsafe execution paths and add automated code checks
- Restrict outbound traffic and replace broad credentials with scoped ones
- Pin tool definitions and begin collecting behavioral baselines
How to secure an MCP server: A short checklist
Teams asking how to secure an MCP server can use this checklist for securing MCP servers in production.
- Require OAuth-based authentication on every remote endpoint
- Validate token audience, issuer, and expiry on each request
- Define a scope for each tool and check it on every call
- Default to deny and require approval for high-risk actions
- Isolate tool execution and restrict outbound destinations
- Pin versions and review any change to tool definitions
- Send detailed logs to central monitoring, without credentials
- Include MCP servers in routine vulnerability management
Each item reduces MCP security threats on its own. Together they make a secure MCP server that holds up under audit. They also link to wider agent controls.
How Gruve helps enterprises secure MCP-enabled systems
Most enterprises know the controls above. Fewer can operate them every hour of every day. Gruve helps enterprises build and operate AI systems in production, and it pairs that work with security operations.
(1) Round-the-Clock Monitoring: Authorization policies and manifest baselines only help when someone watches the alerts. Gruve runs a Managed SOC that combines AI-driven triage with human analysts.
(2) Identity and Access Foundations: Secure MCP deployments depend on strong identity and access controls. Gruve brings expertise in Cisco Identity Services Engine, Secure Access, and XDR integrations, providing a foundation for managing agent identities and enforcing least-privilege access.
(3) Regional Data Requirements: MCP environments can generate telemetry and tool-call logs that are subject to regional data requirements. Gruve offers regional telemetry routing and data-residency options, along with SOC 2 and ISO 27001 certifications, helping global enterprises address security and compliance requirements across jurisdictions.
Conclusion
Controlling MCP tool calls is a business decision before it is a technical one. Every tool you expose is a permission you grant to software that reads untrusted text. Authenticate the caller, then authorize each call, each tool, and each upstream hop. Treat the gateway as one layer among four. Teams that do this can scale MCP in production with evidence for auditors and confidence for boards.
Check all thoughts
