Prompt injection
Content an agent reads — a web page, an email, a document — can carry instructions that redirect its tool calls. Once an agent holds powerful MCP tools, injected text becomes injected action.
Pillar guide
MCP security: the threat model and the controls that contain it.
MCP security covers the risks created when AI agents call real tools — prompt injection, tool poisoning, credential sprawl, token passthrough, and shadow MCP — and the authentication, governance, and observability controls that contain them. MCP Beast puts those controls in one gateway every MCP call must cross.
Threat model
Four ways MCP goes wrong.
MCP gives agents hands. Security is about what those hands can be tricked, poisoned, or quietly wired into doing.
Tool poisoning
A malicious or compromised MCP server can lie in its tool descriptions, exfiltrate the data agents send it, or return results crafted to steer the next step.
Credential sprawl
Direct client-to-server wiring means API keys pasted into every AI client on every machine. Each copy is another place a secret can leak.
Shadow MCP
Developers connect servers to their agents without any central record. Security can't review what it can't see — the same story as shadow IT, at agent speed.
Prompt injection deserves its own deep dive — see prompt injection in MCP.
Anti-pattern
Token passthrough: the shortcut that breaks your audit trail.
The tempting shortcut is to take the OAuth token a user handed your MCP server and forward it straight to the downstream API. It works — and that's the problem. The downstream service now accepts a token that was never issued for it, so it can't distinguish your server from the user, your logs attribute actions to the wrong principal, and any stolen token gains extra reach. The MCP authorization guidance treats passthrough as an anti-pattern for exactly these reasons.
A gateway removes the temptation: clients authenticate to the gateway, the gateway authenticates to each downstream server with credentials scoped to that server, and every hop keeps its own identity. That boundary is what makes the audit trail mean something.
Controls
Authentication, governance, observability.
Authentication
Identity at the front door
Remote MCP uses OAuth 2.1 with tokens scoped to a specific server. MCP Beast terminates client authentication at the gateway, binds access to identity, and manages downstream credentials itself — OAuth-backed connections for SaaS MCPs, Keychain-stored keys on the Mac — so user tokens are never passed through to servers they weren't issued for.
MCP authentication and OAuth, in depthGovernance
Policy before the tool runs
Allow, deny, and rate-limit by org, role, tool, or risk tier — evaluated on every request. High-risk tools can pause for human approval before they execute. Governance lives at the gateway because it's the only point every call must cross.
Enterprise MCP security guideObservability
Audit receipts for every call
Each tool run becomes a structured, searchable record: who called what, through which client, under which policy. That's incident forensics, compliance evidence, and adoption data from the same trail.
AI agent audit logs explainedRelated pillars
Security is why the gateway exists.
Every control on this page assumes a choke point. The MCP gateway page explains that architecture end to end, the MCP proxy page covers the data path underneath it, and the MCP registry page covers vetting servers before they ever reach the gateway.
FAQ
MCP security questions, answered.
What are the main MCP security risks?
The recurring ones are prompt injection (malicious content steering an agent's tool use), tool poisoning (a server whose tool descriptions or behavior are hostile), credential sprawl (API keys copied into every client), token passthrough (forwarding user OAuth tokens to downstream servers), and shadow MCP (servers connected without anyone's knowledge).
What is MCP token passthrough and why is it dangerous?
Token passthrough is forwarding the token a user presented to your MCP server straight through to a downstream API. It breaks the audience guarantee of OAuth: the downstream service can't tell who is really calling, your audit trail records the wrong identity, and a stolen token suddenly works in more places. A gateway avoids it by terminating client auth at the gateway and using its own scoped credentials downstream.
How does MCP authentication work?
The MCP spec uses OAuth 2.1 for remote servers: the client obtains a token whose audience is that specific server, and the server validates it. Local stdio servers inherit the user's machine trust instead. In a gateway setup, clients authenticate to the gateway once and the gateway manages per-server credentials — OAuth where supported, vaulted keys where not.
What is MCP governance?
MCP governance is deciding — and enforcing — who may call which MCP tools under what conditions: allow/deny rules by org, role, tool, or risk tier, rate limits, and human approval gates for high-risk actions. It requires a choke point; that's why governance is a gateway feature rather than a per-client setting.
What does MCP observability look like in practice?
Every tool call recorded with who made it, through which client, against which server and tool, and which policy applied — searchable after the fact. MCP Beast calls these audit receipts: a proof trail for security review, compliance, and understanding what agents actually use.
Get started
Put the controls where every call must pass.
See how policy, identity, and audit receipts work in one gateway — or start locally on your Mac.