How to Secure an MCP Server and Stop Secret Exfiltration

TL;DR

• A malicious or compromised MCP server's primary attack is secret exfiltration: it reads the tokens and API keys your agent holds and sends them to an external endpoint. The OWASP MCP Top 10 ranks token mismanagement and secret exposure as the largest risk in the Model Context Protocol.
• The reliable fix is architectural: route every MCP tool call through a gateway control plane instead of connecting agents directly to servers, so no server ever holds a raw production credential.
• Bifrost enforces deny-by-default MCP tool allow-listing per virtual key. A tool must pass client, request, and virtual-key filters before it can execute, and an unconfigured tool is blocked.
• Scoped authentication keeps secrets off the server: with token exchange the caller's identity token is exchanged per call and never stored, and per-user credentials are encrypted at rest.
• Secrets Detection guardrails catch leaked API keys before they leave the gateway, and HMAC-signed audit logs record every administrative action for SOC 2, GDPR, HIPAA, and ISO 27001 review.

Securing an MCP server starts from an uncomfortable assumption: the server may already be malicious or compromised, and it will try to read every credential your agent holds and exfiltrate it. OWASP ranks token mismanagement and secret exposure as the single largest risk in the Model Context Protocol, ahead of tool poisoning and command injection. The only dependable way to secure an MCP server against that threat is to stop trusting the server and put a control plane between your agents and every tool they can reach. Bifrost, the open-source AI gateway built in Go by Maxim AI, is that control plane: it centralizes MCP tool connections, authentication, and governance so one policy decides which tools run, which secrets they see, and where their output can go.

What Is MCP Security?

MCP security is the practice of controlling which Model Context Protocol tools an AI agent can discover and execute, which credentials those tools receive, and where their output can travel. It treats every connected MCP server as untrusted by default, because a single server with the right tool call can read a secret and send it anywhere.

The Model Context Protocol lets AI models call external tools: reading files, querying databases, hitting internal APIs, and taking actions. That reach is the point of MCP, and it is also the attack surface. When an agent connects directly to a server, the server sees the agent's environment, its headers, and often the raw API keys used to reach downstream systems. Bifrost changes that topology by acting as an MCP gateway that terminates every tool connection centrally, so agents never talk to a server directly and never hand it a production credential. For a fuller map of the threat categories, our breakdown of MCP security risks and how to mitigate them covers the full list.

How a Malicious MCP Server Exfiltrates Secrets

A malicious MCP server exfiltrates secrets by abusing the trust the client places in its tool definitions and its network access. It advertises a benign-looking tool, receives the agent's credentials or context when the tool is called, and forwards that data to an attacker-controlled endpoint before the request ever reaches a legitimate destination.

Three mechanics make this work, and each maps to a documented MCP vulnerability class:

• Tool poisoning. The server embeds hidden instructions in a tool description so the model calls it with sensitive arguments. OWASP MCP03: Tool Poisoning documents how a crafted tool schema hijacks agent workflows.
• Secret exposure. The agent passes an API key, OAuth token, or environment variable into a tool call, and the server reads it directly. This is the token mismanagement risk that OWASP ranks first.
• Uncontrolled egress. The server, once it holds a secret, opens an outbound connection to send it out. Without egress control at a chokepoint, that connection looks like any other tool call.

None of these are stopped by trusting the server to behave. They are stopped by removing the server's access to raw secrets and forcing every tool call through a policy layer. Our guide to the security risks of ungoverned MCP server access walks through how these attacks play out when no gateway sits in the path.

The MCP Security Risks You Have to Design Around

The core MCP security risks fall into four categories: over-broad tool access, secret exposure to untrusted servers, uncontrolled data egress, and no audit trail of what tools actually did. Each risk has a concrete control at the gateway layer, and locking down an MCP deployment means closing all four rather than any one in isolation.

The table below maps each risk to what a malicious or compromised server does and the control that neutralizes it.

Treating these as one system is the difference between a checklist and a defensible posture. Teams that need a structured evaluation of governance tooling can start with our roundup of MCP gateway tools for governing server access, and the governance resource hub collects the control patterns in one place.

How to Secure an MCP Server With a Gateway Control Plane

To secure an MCP server, place a gateway between your agents and every server so the gateway, not the server, holds the credentials and enforces policy. The Bifrost AI gateway connects to external MCP servers as a client and exposes a governed tool surface to agents, which means one configuration decides which tools exist, who can call them, and what data leaves.

This inverts the default trust model. Instead of each agent trusting each server, every request flows through a single enforcement point where four controls apply in sequence:

1. Tool allow-listing decides which tools are even visible to the model.
2. Scoped authentication decides what identity and credentials a tool call carries.
3. Guardrails and egress control decide whether a request or response containing secrets is allowed to pass.
4. Audit logging records every administrative change and tool decision.

Because these run at the gateway rather than inside each agent, the policy is consistent across every model, every SDK, and every environment. The MCP overview documents how Bifrost operates as both an MCP client and server, and our comparison of the differences between an MCP gateway, proxy, and server explains why the gateway topology is the one that supports enforcement.

Tool Allow-Listing: Deny-by-Default MCP Tool Access

Deny-by-default tool allow-listing means a tool cannot execute unless it has been explicitly permitted, and an unlisted or unconfigured tool is blocked rather than allowed. Bifrost applies three stacked levels of tool filtering, and a tool must pass all applicable levels before it reaches the model.

The three levels compose so that the narrowest policy wins:

• Client configuration. The tools_to_execute field on each MCP client sets the baseline. An empty list means no tools are available, which is the deny-by-default posture.
• Request headers. Individual requests can filter the tool set further for a single call.
• Virtual key configuration. Virtual keys enforce a strict allow-list per consumer. A virtual key with no MCP configuration exposes no tools at all, and an inactive or expired key is rejected at tool execution time with a 403.

This is enforced twice, at inference time and again when a tool actually executes, so a request cannot smuggle a disallowed tool past the filter. Configuring MCP tool filtering per virtual key gives each team, customer, or agent exactly the tools it needs and nothing more. For larger fleets, MCP tool groups bundle curated tool subsets and attach them to virtual keys, teams, or providers, so a reusable "read-only" or "billing tools" group can be granted or revoked in one place. This least-privilege model is the single most effective control against a malicious server, because a poisoned tool the model can never see is a tool it can never call.

MCP Authentication and Scoped Secret Handling

MCP authentication controls which identity and credential each tool call carries, and scoped secret handling ensures a server never receives a raw shared production key. Bifrost supports several MCP auth types so credentials can be bound to the caller instead of embedded in the server, and the most sensitive of these never persists a token at all.

The auth types below let you match the credential model to the trust level of each server.

Per-user authentication binds a credential to a specific Virtual Key, signed-in user, or session ID, so a compromised server cannot reuse one user's token to act as another. Token exchange goes further: it swaps the caller's identity-provider token for a scoped upstream token on every call and never stores the result, which removes the standing secret a server would otherwise try to read. Configuring MCP authentication this way means the gateway holds identity, not the tool, and our guide to MCP server authentication for agent tool access covers the decision flow for each type.

Egress Control, MCP Guardrails, and Secret Redaction

MCP guardrails inspect the content of tool requests and responses and block or redact sensitive data before it can leave the gateway. Bifrost runs Secrets Detection as a built-in guardrail that scans text for leaked API keys, tokens, private keys, and credentials, so a secret captured by a malicious server is caught at the boundary rather than after it has already left.

Secrets Detection uses embedded Gitleaks rules and runs entirely inside the gateway, with no external moderation service to configure. When it finds a secret, it applies one of three actions:

• Detect only flags the match without changing the request.
• Block stops the request or response from proceeding.
• Redact rewrites the secret in place, with runtime, logs-only, or reversible redaction modes.

Using logs_only redaction lets a model call proceed on the original text while preventing raw secrets from ever being written to logs or exported traces, which closes a common exfiltration path through observability pipelines. Beyond secret patterns, Bifrost guardrails support AWS Bedrock Guardrails, Azure Content Safety, and custom regex for organization-specific PII rules. Combined with data access control, these controls give you a policy chokepoint where every request carrying a credential is inspected before it reaches a model or returns to an agent. Our MCP gateway resource page details how these controls fit the broader access-control model.

Audit Logs and Fleet Visibility: AI Gateway + Bifrost Edge

Audit logs record who changed a policy, when, and which resource was affected, giving you the trail regulators and incident responders require. Bifrost writes audit entries that can be signed with an HMAC key, retained for a configurable period, filtered in the dashboard, and exported as JSON, JSON Lines, or Syslog, with optional archival to S3 or GCS for long-term, off-box retention.

Signed audit logs are the record that turns "we think the policy held" into "we can prove which tools ran and who authorized them," which is what SOC 2, GDPR, HIPAA, and ISO 27001 reviews ask for. Configuring audit logs with an HMAC key makes each entry verifiable, and the Bifrost Enterprise feature set extends this with RBAC and in-VPC deployment for regulated environments.

The gateway governs the MCP traffic that is configured to flow through it. The gap is the shadow AI on employee machines: coding agents and desktop apps where engineers wire MCP servers directly into their tools with no policy in between. This is where the AI gateway pairs with Bifrost Edge: the gateway remains the control plane where tool allow-lists, auth, guardrails, and audit logs are defined, and Bifrost Edge extends that same governance to every laptop. Edge inventories the MCP servers configured inside each AI app across the fleet and enforces per-server allow or deny decisions on the device itself, so a denied server cannot run even in an app that had it configured before the policy existed. Bifrost Edge is currently in alpha. Our write-up on MCP server governance across the gateway and endpoint explains how the two layers combine.

MCP Security Best Practices Checklist

The core MCP security best practices are to trust no server by default, grant the fewest tools possible, keep secrets off the server, inspect every request for leaked credentials, and log every action. Applied together, these practices remove each stage a malicious server would need to exfiltrate data.

Use this checklist to lock down an MCP deployment:

• Deny by default. Start every virtual key with no tools and add only what each consumer needs, using per-key tool filtering and tool groups.
• Scope every credential. Prefer per-user OAuth or token exchange so no server holds a shared production key.
• Inspect for secrets. Enable Secrets Detection with block or redact actions on both inputs and outputs.
• Control egress. Route all tool traffic through the gateway so there is a single chokepoint to inspect and log.
• Log and sign. Turn on HMAC-signed audit logging with retention that matches your compliance window.
• Extend to endpoints. Bring ungoverned MCP usage on employee machines under the same policy with Bifrost Edge.

Teams evaluating tooling against these practices can compare options in our list of MCP governance tools to secure your fleet and the roundup of MCP gateways for security and compliance. The official Model Context Protocol security best practices document the protocol-level guidance these controls implement.

Frequently Asked Questions

What is MCP security?

MCP security is the practice of controlling which Model Context Protocol tools an AI agent can discover and run, which credentials those tools receive, and where their output can go. It treats every connected MCP server as untrusted, because one server with a poisoned tool can read a secret and exfiltrate it. The controls that enforce it are tool allow-listing, scoped authentication, guardrails, and audit logging.

Are MCP servers a security risk?

Yes. Any MCP server an agent connects to can read the data passed into its tool calls, including API keys and tokens, and can open outbound connections to send that data elsewhere. The risk is not hypothetical: OWASP ranks token mismanagement and tool poisoning among the top MCP vulnerabilities. The mitigation is to route MCP traffic through a gateway so no server receives raw secrets or unfiltered tool access.

How do you secure MCP?

You secure MCP by placing a gateway control plane between agents and servers, then applying four controls: deny-by-default tool allow-listing so only approved tools run, scoped authentication so servers never see shared production keys, secrets-detection guardrails so leaked credentials are blocked or redacted, and signed audit logs so every action is recorded. Bifrost enforces all four from a single MCP gateway configuration.

What are the top 10 vulnerabilities in MCP security?

The OWASP MCP Top 10 for 2025 catalogs the leading risks, led by token mismanagement and secret exposure, followed by tool poisoning, command injection, and related weaknesses. Most reduce to two root causes: servers receiving credentials they should never see, and tools running that were never explicitly approved. A gateway that scopes credentials and enforces least-privilege tool access addresses the majority of the list.

Can a malicious MCP server steal your API keys?

A malicious MCP server can steal API keys if the agent passes them into tool arguments or exposes them in its environment, because the server reads whatever data reaches it. Preventing this means keeping keys off the server entirely: use token exchange so an identity token is swapped per call and never stored, and enable Secrets Detection so any leaked credential is caught before it leaves the gateway.

What is the difference between MCP tool filtering and MCP authentication?

MCP tool filtering controls which tools an agent can see and execute, enforcing a deny-by-default allow-list per virtual key. MCP authentication controls what identity and credential each permitted tool call carries. Filtering stops an agent from calling a tool at all; authentication ensures that when a tool is called, it runs under a scoped identity rather than a shared production key. Both are needed to secure an MCP server.

Secure Your MCP Deployment With Bifrost

Locking down MCP tool access is an architecture decision, not a setting: you secure an MCP server by removing its access to raw secrets and forcing every tool call through a control plane that enforces least privilege, scoped auth, guardrails, and audit logs. The open-source Bifrost gateway provides that control plane as an AI gateway built for enterprises running mission-critical AI workloads, and Bifrost Edge extends the same governance to every machine. To see how the MCP gateway centralizes tool connections, authentication, and secret handling in your environment, book a demo with the Bifrost team.