The Model Context Protocol (MCP) lets agents call tools and fetch data, but an explanation of what MCP is does not tell you how to secure the server that implements it. That server holds delegated credentials and live business data, and it acts on instructions interpreted by a large language model (LLM). A working connection says nothing about whether the execution path is attributable, contained, or recoverable.
TL;DR Authenticate MCP clients with OAuth 2.1 per the current spec, including the issuer validation the 2026-07-28 revision made mandatory. Authorize every tool invocation, and default to deny, scoped to principal, tenant, and action. Run tool execution in locked-down containers. Have the host inject credentials and prevent the container from accessing them. Log every call with the initiating identity, cap request rates, and keep a kill switch per tool and per tenant. Get started to run your agent connectors behind one hosted, authenticated MCP server instead of hardening each one yourself.
Why Is an MCP Server a Different Trust Boundary Than a Standard API? A standard API executes the request it receives. An MCP server executes whatever an LLM decides to do after reading text, some of which is untrusted. One process can reach private data through delegated credentials. It also receives untrusted instructions such as prompt injection through tool responses and descriptions. Outbound channels can then carry data out.
Engineers designed web application firewalls and API gateways for static request-response traffic. They can check a token and rate-limit a path, but they cannot tell whether the text inside a tool response is data or an instruction that will steer the agent's next privileged call. That blind spot is why an MCP boundary must adhere to a zero-trust AI posture by verifying every invocation and assuming that any input may be hostile.
The person who creates this exposure is often not an engineer. A revenue operations lead or technical product manager clicks "Connect" on the Salesforce or HubSpot integration inside Claude, and the threat model never crossed their desk. Read scopes allow API access to specific customer relationship management (CRM) objects. The connected user's data-layer permissions determine which records the integration can read for broadly privileged CRM users, which may still include a large share or all of the customer record set. Write scope can change live records. Scope decisions at that click are security decisions.
Independent scans show how far spec requirements sit from deployed reality.
Finding Source Scope 73% of servers had vulnerabilities (143,000+ across 268,000 tools) August 2026 scan 25,000 live MCP servers 1,862 exposed servers with zero authentication Dark Reading, July 2025 Internet scan MCP servers present in at least 80% of observed cloud environments; 5% of those environments run at least one internet-facing MCP server Early 2026 cloud survey Cloud environments
Scan-derived percentages depend on scanner methodology, which varies between studies. Still, every study points the same direction: most deployed servers fail the first control, which is knowing who is calling.
How Should You Authenticate MCP Clients Under the Current Spec? HTTP-transport MCP servers must use OAuth 2.1 under the authorization spec , which remains the normative auth text. API authentication in general verifies who is calling; the MCP authorization spec pins down exactly how, with MUST-level requirements for PKCE, resource metadata discovery, and token handling. The TLS baseline requires TLS 1.2 or higher with CA-issued certificates.
The 2026-07-28 protocol revision made issuer (iss) validation mandatory. This closes mix-up attacks in which an attacker tricks a client into completing an auth flow against the wrong authorization server. The same revision removed the handshake and the Mcp-Session-Id header, so each request is now self-describing. If your server still keys authorization state to a session identifier, that assumption no longer holds. Both changes date to 2026-07-28, so check which spec revision any implementation reference targets.
Servers must also avoid a mistake the spec calls out directly: "MCP servers MUST NOT pass through the token it received from the MCP client" when calling upstream APIs. The authorization server issued the token for your MCP server, and the upstream API should reject it during audience validation. Follow the upstream credential guidance and hold a separate credential that your server obtains through its own grant, so an attacker cannot replay a leaked client token against the systems behind you.
The normative authorization spec defines requirements that most deployed servers fail to meet.
Requirement Status Standard/requirement note OAuth 2.1 for authorization servers MUST OAuth 2.1 PKCE for all clients MUST OAuth 2.1 §7.5.2 Protected Resource Metadata MUST RFC 9728 Authorization Server Metadata MUST RFC 8414 Resource Indicators (resource param) MUST RFC 8707 Bearer token in Authorization header MUST Every HTTP request Tokens never in URI query string MUST OAuth 2.1 §5 HTTPS for all auth server endpoints MUST Authorization spec Audience validation MUST Reject tokens the authorization server did not issue for this server Issuer (iss) validation MUST Added 2026-07-28; closes mix-up attacks Dynamic Client Registration SHOULD RFC 7591
Requirements from the 2025-06-18 authorization spec, still the normative auth text, plus the iss validation added 2026-07-28.
Against those requirements, one measurement put OAuth adoption at 8.5%, showing how far most deployments sit from the spec. If you meet the requirements, you get a validated identity and its scopes on every request. Those become the inputs to the next layer, which decides what that identity may actually do.
How Do You Sandbox and Authorize Tool Execution? Recheck invocation authorization for every tool call. Connection-time validation cannot establish whether the authorization policy permits a later invocation. The check is deny-by-default and evaluates which principal is asking, which tenant's data is in play, and which action the principal requests. A token that was valid at handshake proves nothing about whether this call is permitted right now. Agent access control covers the design patterns; the MCP-specific point is that enforcement occurs at the invocation boundary inside your server.
Assume attackers will eventually compromise or trick a tool, and size the blast radius in advance. Apply container isolation controls by running tool execution in a non-root container with a read-only root filesystem and capDrop: ["ALL"]. Disable networking with --network none or enforce a strict egress allowlist, then set CPU and memory caps. Use host-injected credentials and keep credentials out of the container entirely, so API keys stay on the host. The host injects them at the remote procedure call (RPC) layer when it calls the MCP server, so a compromised tool has nothing to steal. The EscapeRoute vulnerabilities, including CVE-2025-53110 and CVE-2025-53109, show why the filesystem boundary needs the same rigor. A naive path-prefix check and a symlink bypass in the Filesystem MCP Server granted full read/write access outside the intended directory.
Tool descriptions constitute an attack surface because the model can read them. Tool poisoning involves malicious instructions embedded in a tool description that remain invisible to the user yet direct the model. Rug pulls are the delayed variant, where a server mutates a description after the client approved it. The operational defense hashes every tool description at deployment, verifies the hash on every tools/list response, and refuses tools that drift. Combined with per-invocation authorization, a poisoned description can suggest an action but cannot get it executed outside the caller's scope. Authentication, authorization, and isolation cover the request path; production hardening addresses what happens around it.
What Does Production Hardening Add Beyond Auth and Sandboxing? The runtime should consume credential references and exclude raw tokens from its inputs. Nothing secret may reach the tool's output or logs, because the tool's output flows straight into a model's context window . A deployment study found that 53% of deployments relied on long-lived static secrets: a long-lived key that leaks in a log line can remain valid for months.
Apply runtime abuse limits by rate-limiting per principal and per tenant and adding concurrency ceilings, per-call timeouts, and payload size caps. An agent stuck in a retry loop imposes the same load on your backend as a denial-of-service attack, and the limits should treat it accordingly.
Attributable telemetry makes incidents traceable. Log every request, tool invocation, authentication failure, authorization failure, and policy violation with the initiating user or token, so you can answer "who caused this write" after the fact. Agent observability encompasses the broader tracing that explains why the agent made the call in the first place. Use session hygiene to keep stolen tokens cheap: set access token lifetimes to 1 hour or less and rotate refresh tokens on each use, so that a captured token expires before an attacker can fully map what it can reach.
Contain failures with kill switches per tool and per tenant, plus a tested credential revocation path. The Postmark MCP incident provides the motivating case. It marked the first discovery of a malicious MCP server in the wild. Starting with version 1.0.16, the server quietly copied every email to the developer's personal server. That behavior can persist across releases until someone audits the package, so the fast levers are a pre-tested revocation path and a per-tool kill switch. Both get harder to pull once one agent holds credentials for more than one server.
What Changes When One Agent Connects to Many MCP Servers? Each of those controls is per-server, and the realistic deployment is one agent authenticated to five or ten SaaS sources at once. That means N OAuth flows to configure and keep spec-current, N audit trails with no shared identity across them, and N secret stores to rotate. No shared system can answer "what did this agent touch today."
Two risks exist only when N is greater than one. Cross-server relay requires no direct channel between servers, because they can instruct the model itself to act as a relay between supposedly isolated components. Invisible scope expansion creates the second risk. A user authorizes an agent to read email, and a second server exposes the code repository. The agent's effective scope is now email plus code, even though no administrator approved that combination.
A shared MCP endpoint centralizes authentication, per-call permissioning, and logging through an MCP gateway pattern. This replaces N separate implementations for authentication, per-call permissions, and logging.
A shared endpoint also reduces the number of direct connections to individual data sources. It can pre-materialize a unified context layer . The agent then queries a single permissioned layer without fanning out across sources using separate credentials.
How Do Airbyte's agentic platform Reduce Exposed Credentials and Auth Flows? Airbyte's agentic platform place a single authenticated boundary in front of every source. Managed Auth stores platform credentials and each agent connector's credentials, including OAuth tokens and API keys, and automatic OAuth refresh keeps raw secrets away from the agent. More than 50 agent connectors sit behind Agent MCP, Airbyte's single hosted MCP server at mcp.airbyte.ai/mcp, which works with Claude, Claude Code, ChatGPT, Codex, Cursor, VS Code, and Windsurf. Every tool call is logged with the connector used and the action taken, and workspaces isolate credentials across teams and tenants. Airbyte is SOC 2 Type II and ISO 27001 certified.
Which interface you reach for depends on where the security decision lives. Agent SDK moves scope decisions out of an ad-hoc "Connect" click and into code your team can review. Hence, the connectors an agent can call, and the actions each one permits, live in a version-controlled configuration instead of a setting chosen once in a console. Agent CLI covers the operational side the hardening steps above depend on: you can list which connectors and scopes are live, run that check in a continuous integration (CI) step before a deploy, and revoke a connector from the terminal when a tool starts behaving the way the Postmark package did, without waiting on a dashboard.
What Should You Harden First on an MCP Server? Start with authentication, because it gates everything. An unauthenticated server has no principal to authorize, no identity to log, and no scope to limit. The harder problem for most teams is applying these controls consistently across the five or ten servers that a production agent talks to, which is where per-server hardening stops scaling.
Airbyte's agentic platform applies that single boundary across every source an agent touches, with Managed Auth for credential isolation, one hosted MCP server for authenticated access, and per-call logging for attribution. Agent SDK keeps scope definitions in reviewable code, and Agent CLI makes those connections auditable and revocable from the terminal. The controls in this article apply across all servers at once rather than one at a time.
Get a demo to see one set of security controls applied across every source your agents touch.
Frequently Asked Questions Do Local Stdio MCP Servers Need OAuth? The authorization spec applies to HTTP transports. Stdio-transport servers should retrieve credentials from the environment and require local filesystem and command restrictions. Limit the filesystem paths and shell commands the server can reach, because a local server runs with your user's privileges and can reach anything you can.
Is a Read-Only MCP Server Safe by Default? A read-only MCP server still raises a data residency question because every call to a hosted model sends the retrieved records outside your environment as part of the context window. Scope settings control what the agent can fetch, while the hosted model determines where the fetched data travels afterward.
How Do You Vet a Third-Party MCP Server Before Installing It? Audit before install. Install signed, containerized distributions, avoid raw packages and run tool descriptions through a scanner like mcp-scan before approving them. Expect little help from the maintainers; a scan of 1,000 MCP servers found 0% shipped security documentation.
What Is a Confused Deputy Attack in MCP? A confused deputy attack occurs when an attacker tricks a server that holds delegated authority into acting on the attacker's behalf. The victim's credentials then perform the attacker's action. Alert when audit entries show different initiating and acting identities: the identity that triggered the call is not the identity whose token executed it.
