MCP Security Best Practices: Enterprise Checklist 2026
TL;DR
- An MCP server carries the permissions of every tool it exposes, so MCP security is an authorization problem before it is a network problem.
- Bifrost supports six MCP authentication modes: none, headers, per-user headers, OAuth 2.0, per-user OAuth, and token exchange. Choosing the wrong one is the most common enterprise mistake.
- Tool filtering restricts which tools a virtual key can invoke through strict allow-lists, which shrinks the agent's capability surface before any request is made.
- Guardrails can inspect tool arguments before execution and tool results before they return, so prompt injection is blocked at the tool boundary rather than detected afterward.
- Token exchange carries the caller's identity-provider token per call and persists no credential, but revocation is reflected within the cached token lifetime of up to five minutes rather than instantly.
An MCP server that an agent can reach carries the permissions of every tool it exposes, and most enterprise deployments grant that reach with a static shared credential and no tool allow-list. MCP security best practices exist to close that gap, and the ones that matter are enforced at request time rather than written into a policy document. Bifrost, the open-source MCP gateway built in Go by Maxim AI, is the best choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability, and it applies these controls on every tool call. This checklist covers the risks, the six authentication modes, tool-level least privilege, and the audit evidence an enterprise MCP deployment needs.
What MCP Security Covers
MCP security is the set of controls governing which agents can reach which Model Context Protocol servers, which tools on those servers they may invoke, under whose identity, and with what record left behind. It spans authentication, authorization, content inspection, and audit, and it differs from ordinary API security in one respect that changes the whole design.
That difference is the caller. A traditional API client executes a fixed set of calls written by a developer. An MCP client is a model choosing tool calls from a list at runtime, with arguments it composes itself, influenced by whatever text is in its context window. The authorization boundary has to hold against a caller that can be persuaded.
The official MCP security best practices in the specification cover the protocol-level requirements, including token audience validation and the prohibition on token passthrough. Enterprise deployments need those plus a policy layer, because the specification governs one client and one server rather than a fleet of agents reaching dozens of servers.
Our companion analysis of MCP security risks and how to mitigate them covers the threat model in more depth than a checklist allows.
The MCP Security Risks Enterprises Actually Face
Five risk classes account for most real MCP exposure, and each maps to a specific control rather than to general hardening. Grouping them this way is what turns a threat list into a configuration.
| Risk | How it happens | Control |
|---|---|---|
| Over-broad tool access | An agent can invoke every tool on every connected server | Tool filtering with strict allow-lists per virtual key |
| Shared credential blast radius | One static token grants all users the same upstream access | Per-user auth or token exchange |
| Prompt injection into tool calls | Untrusted content persuades the model to call a tool with harmful arguments | Guardrails inspecting arguments before execution |
| Data exfiltration through tool results | A tool returns sensitive data that flows back into the context | Guardrails inspecting and redacting results |
| No attribution | Tool calls cannot be traced to a person or an application | Virtual keys plus audit logging |
The first two are configuration failures and are the most common. OWASP's practical guide for secure MCP server development covers the server-side half of this; the controls below are the client and gateway side, which is where enterprises have the most control, because it applies uniformly across servers they do not own.
The specific failure mode of ungoverned access is worked through in our write-up on the security risks of ungoverned MCP server access.
The MCP Security Best Practices Checklist
These are the MCP security best practices to implement in order. The sequence matters because each step narrows the surface the next one has to cover.
- Route MCP traffic through a gateway. Nothing else is enforceable until tool calls pass through one layer. Bifrost as an MCP gateway connects to external tool servers and exposes tools to clients through a single point.
- Choose an authentication mode deliberately per server. The default of a shared static header is correct for some servers and wrong for anything user-scoped.
- Apply strict tool allow-lists. Grant the tools a role needs, not every tool the connected servers expose.
- Inspect tool arguments before execution. Treat model-composed arguments as untrusted input, because they are.
- Inspect tool results before they return. A tool that reads data can return more than the request warranted.
- Require approval for high-consequence tools. Autonomous execution is appropriate for read operations and rarely for writes.
- Attribute every call to an identity. Virtual keys make tool calls traceable to a team, application, or person.
- Record configuration changes separately from traffic. Auditors ask for who changed the policy and who used it as two different questions.
- Test revocation, not just provisioning. Offboarding is where credential models differ most, and the difference is usually invisible until it matters.
The rest of this guide covers the items with the most implementation detail behind them.
Authentication: Choosing the Right MCP Auth Mode
MCP authentication decides which credential reaches the upstream server and whose identity it represents. Bifrost supports six MCP authentication modes, and the choice is per server rather than global.
| Mode | Who supplies the credential | Best suited to |
|---|---|---|
none |
Nobody | Public servers and local STDIO tools needing no key |
headers |
Admin, once | Shared API keys and bearer tokens used by the whole team |
per_user_headers |
Each end-user, lazily | Per-user API keys and signed tokens keyed to a person |
oauth |
Admin, once | A shared third-party service the whole team uses |
per_user_oauth |
Each end-user, lazily | Per-user services such as Notion, GitHub, or Sentry |
token_exchange |
The caller's identity provider, per call | Enterprises wanting no persisted per-user credential |
Server-level modes (headers, oauth) give every caller the same upstream access, which is the shared-credential blast radius from the risk table. Per-user modes store a credential against the caller's identity and reuse it on later calls, which restores attribution at the upstream service.
Token exchange is the third shape and the most interesting for enterprises. Each tool call carries the caller's identity-provider token, Bifrost exchanges it on a cache miss with a short in-memory cache, and no credential is persisted per caller. The trade-off is explicit and worth stating in a security review: because the exchanged token is cached, removing a user at the identity provider is reflected within the cached lifetime of up to five minutes, or the provider's own token expiry if shorter, rather than instantly. It also requires identity authentication on every request, so a virtual key alone is not sufficient.
Per-user auth applies to HTTP and SSE connections. STDIO connections inherit their environment from the spawned subprocess and have no per-call auth model, which is a reason to prefer remote servers for anything user-scoped. Our explainer on MCP authentication covering OAuth, API keys, and token management works through the selection logic, and securing agent tool access at the MCP server covers the upstream side.
Least Privilege: Tool Filtering and Tool Groups
Authentication decides whether an agent reaches a server. Authorization decides which tools on that server it may call, and this is where most MCP deployments are far more permissive than intended, because connecting a server exposes everything on it by default.
MCP tool filtering restricts the tools available to a given virtual key using strict allow-lists. The effect is not only security. Every tool definition occupies context on every call, so a narrower allow-list reduces token spend at the same time it reduces the capability surface.
MCP tool groups extend filtering into reusable curated collections that attach to virtual keys, teams, customers, users, providers, or API keys, and are enforced at request time. Curating a group once per role is more durable than maintaining a list per key, and it makes the granted capability set reviewable as a single artifact.
Two further controls belong here. Role-based access control governs which operators can change MCP configuration at all, and MCP with federated auth turns existing enterprise APIs into MCP tools without writing glue code, which keeps tool surfaces inside an already-governed boundary. The wider operational picture is covered in our guide to MCP server governance best practices and tools.
Guarding Tool Calls Against Prompt Injection
Prompt injection becomes materially more dangerous once tools are attached, because the model is no longer only producing text. Injected content that persuades a model to call a deletion tool, or to pass a customer record into a search query, has an effect that no output filter can undo after the fact.
The control that works is inspection at the tool boundary, in both directions. Guardrails in Bifrost can target MCP tool calls at three points: before the tool executes, after the tool returns, or both. On the input path a rule inspects the arguments and can allow, redact, or block before execution. On the output path it inspects a successful result and can allow, redact, or block before the result reaches the model. A block at either boundary stops processing.
Three Bifrost-managed check types cover most enterprise policy without an external dependency: secrets detection using local Gitleaks rules for credentials and tokens, custom regex using local RE2 patterns for organization-specific identifiers, and prompt guardrails that apply a natural-language policy through a configured judge model. External providers including Presidio, Azure AI Language PII, AWS Bedrock Guardrails, Azure Content Safety, and Google Model Armor attach to the same rule engine.
Blocking before execution is the part that distinguishes this from monitoring. Detecting a harmful tool call after it ran is an incident report, not a control.
Human Oversight and Approval for Agent Tool Execution
AI agent security depends on where the human sits in the loop. Full autonomy for every tool is rarely the right default, and requiring approval for every tool makes agents useless, so the decision has to be per tool rather than global.
Agent Mode supports autonomous tool execution with configurable auto-approval, which lets read-only and low-consequence operations run without interruption while write operations, deletions, and anything touching money or customer records require an explicit decision. Tool execution covers the approval and validation controls available on that path.
A workable default for most enterprises: auto-approve reads, require approval for writes, and never auto-approve anything irreversible. Approval settings belong in the same review cycle as the tool allow-list, since adding a tool to a group silently changes what an agent can do without asking.
Audit, Evidence, and Revocation
Security controls that leave no record cannot be demonstrated to an auditor, and MCP deployments generate two distinct evidence classes that are easy to conflate.
Audit logs record administrative activity: who changed which resource and when. Entries can be signed with an HMAC key, retained for a configured period, exported as JSON, JSON Lines, or Syslog, and archived to S3 or GCS for long-term retention. Request-level telemetry is separate, flowing through built-in observability and log exports into the systems a security team already reads.
Keeping them distinct matters because a reviewer asking "who granted this agent access to the payments tool" and a reviewer asking "which agent called it" are asking different questions with different answers.
Revocation deserves its own test. Deleting a virtual key stops access at the gateway immediately. Removing a user at the identity provider under token exchange takes effect within the cached token lifetime rather than instantly, as noted above. Neither behavior is wrong, but only one of them matches what most offboarding runbooks assume, and the gap is worth measuring before an incident rather than during one.
Where the MCP Gateway Fits
An MCP gateway is the enforcement point that makes every control above apply uniformly across servers an enterprise does not own or operate. Without one, each of these decisions is made per client application, which means it is made inconsistently.
Centralizing has three concrete effects. Policy changes apply immediately across all agents rather than requiring a release per service. Credentials are held in one place and rotated once. And tool-call telemetry has a single shape, which is what makes the audit evidence usable. The Bifrost MCP gateway also serves as an MCP server to clients such as Claude Desktop and Cursor, so the same governed tool set reaches desktop agents rather than only backend services.
For teams evaluating the architecture rather than the controls, our complete guide to MCP gateways for enterprise AI teams covers the deployment patterns, and the MCP gateway resource page covers the cost and access-control effects at scale.
Frequently Asked Questions
What are the security best practices for MCP servers?
Route MCP traffic through a gateway, choose an authentication mode per server rather than globally, restrict tools with strict allow-lists, inspect tool arguments before execution and results before they return, require approval for write and irreversible operations, attribute every call to an identity, and keep administrative audit records separate from request telemetry.
Is MCP a security risk?
MCP itself is a protocol, and the risk comes from how it is deployed. The common exposures are over-broad tool access, a shared static credential used by every caller, and prompt injection influencing tool arguments. All three are configuration problems addressable at the gateway rather than flaws in the protocol.
How do you secure MCP?
Secure MCP by treating tool invocation as an authorization decision made per request. Authenticate the caller, resolve which tools that identity may reach, inspect the arguments before execution, inspect the result before it returns, and record both the call and any configuration change. MCP tool filtering and guardrails are the two controls doing most of that work.
What is the difference between MCP authentication and MCP authorization?
Authentication establishes which credential reaches the upstream MCP server and whose identity it represents. Authorization decides which tools on that server the caller may invoke. Server-level authentication with no tool filtering is the most common enterprise gap, because connecting a server exposes every tool on it by default.
Does an MCP gateway replace securing the MCP server itself?
No. A gateway governs which agents reach which tools and what flows through, while the server still needs its own hardening, input validation, and least-privilege backing credentials. The two are complementary: the gateway applies uniform policy across servers an enterprise does not control, and server-side security covers the ones it does.
How should MCP access be revoked when someone leaves?
Deleting or deactivating the virtual key stops gateway access immediately. Under token exchange, removing the user at the identity provider takes effect within the cached token lifetime of up to five minutes, or sooner if the provider's token expiry is shorter. Offboarding runbooks should do both and state the expected delay rather than assume instant propagation.
Securing MCP with Bifrost
MCP security best practices reduce to a short list applied consistently: one enforcement point, deliberate authentication per server, strict tool allow-lists, inspection in both directions at the tool boundary, approval on consequential operations, and two separate evidence trails. Implementing them at the gateway is what keeps them uniform as the number of agents and connected servers grows, and it is the same reason governance controls belong in infrastructure rather than in each client. Bifrost Enterprise covers the deployment options for regulated and isolated environments.
To see how MCP security works against your own tool inventory, book a demo with the Bifrost team, or start with the MCP overview documentation to map your current servers onto these controls.
