MCP Security Architecture: Authentication, Scopes and Transport
The Model Context Protocol solved a real, boring problem: every agent needed its own bespoke glue to reach every tool and data source, and none of it was reusable. MCP standardises that connection — a common way for an AI host to discover and call tools, read resources, and fetch prompts from a server. The productivity win is obvious, which is why MCP servers are proliferating inside organisations. The security consequence is just as real: a standard interface to your tools and data is also a standard interface for an attacker, and much of it is being deployed faster than anyone is reviewing it.
The pieces, and why each exists
MCP has a small cast. A host (the agent, IDE, or app) runs an MCP client that speaks the protocol. It connects to one or more servers, each of which exposes some mix of tools (actions the model can invoke), resources (data it can read), and prompts (reusable templates). The server is the interesting part for us: it is the thing holding credentials to a real backend — a database, a SaaS API, a filesystem — and deciding what the agent may do there. Everything security-relevant comes down to three questions: who is the server willing to talk to (authentication), what is it willing to let them do (scopes), and how do the messages travel (transport).
Authentication: who gets to call the server
The earliest MCP deployments largely skipped this — a local server over stdio felt trusted, so many exposed tools with no authentication at all. That assumption breaks the moment a server is reachable over the network or shared between users. Recent versions of the specification address it directly by defining an OAuth 2.1-based authorization framework: the server acts as a protected resource, the client obtains a scoped access token from an authorization server, and calls carry that token. The upgrade matters, but only if you adopt it — a remotely reachable MCP server with no authentication is an open door to whatever backend it holds credentials for.
Scopes: what the server lets the agent do
This is where MCP meets the confused-deputy problem head-on. The server holds real credentials to a backend; the agent decides what to ask for by reading text it does not fully trust. If the server exposes broad, coarse tools — “run any query,” “read any file” — then an injected instruction that reaches the agent can drive those tools with the server's full authority. Two abuses are specific to this layer. Tool poisoning hides instructions in a tool's own description or metadata, which the model reads as it decides what to call. Token passthrough — a server accepting and forwarding a token it was never the intended audience for — lets it be used as a confused proxy into systems it should not reach. The defence is narrow, task-specific tools and per-action authorization at the server, not a single god-tool guarded by hope.
Transport: how the messages travel
MCP runs over two main transports. stdio connects to a local subprocess — no network, but the server runs with the host's local privileges, so a malicious or compromised server package is code execution on the box. HTTP-based transport (including server-sent events for streaming) exposes the server over the network, which brings the usual web concerns: it must be over TLS, it must authenticate, and it must not be bound to a public interface by accident. A remote MCP server that is unauthenticated or plaintext is trivially hijacked or eavesdropped, and because it fronts a real backend, the payoff for doing so is high.
- Inventory the MCP servers running in your environment and, for each, ask two questions: does it require authentication, and what backend credentials does it hold? An unauthenticated server fronting anything sensitive is the finding.
- Read one server's tool definitions as an attacker would: is there a broad “run anything” tool, and could instructions hidden in a tool description or a processed document steer it? Narrow tools shrink the damage.
Discovering every MCP server, mapping its scopes and transport, and driving injection through the tools it exposes is a controlled engagement — precisely what our assessment and SecStudio agent-testing tooling are built to run.
Deploying MCP without opening a door
- Authenticate every server. Adopt the OAuth-based authorization flow; never expose an unauthenticated server beyond a genuinely trusted local boundary.
- Expose narrow tools. Fine-grained, least-privilege tools with per-action checks beat one broad tool — the server's scope is your blast radius.
- Secure the transport. TLS for anything remote, bind local servers to localhost, and treat a third-party server package as code you are choosing to run.
- Vet tools and their metadata. Review tool descriptions and updates for hidden instructions, and don't let a server forward tokens it was not the audience for.
MCP is genuinely good engineering — it makes agents composable and will only spread. But standardising the connection between models and the real world standardises the attack surface too, and the protocol's own security features only help the teams that actually turn them on. The servers being spun up this quarter, holding live credentials and reachable over the network, are exactly the shadow infrastructure that no one has inventoried. You cannot secure an MCP server you don't know is running — and right now, most organisations couldn't list theirs.