MCP security: secure configuration, identity and gateway authorization
How to run the Model Context Protocol safely in production: an MCP gateway, authorization and scoping, and non-human identity controls that keep agent tooling under control.
Definition
The Model Context Protocol (MCP) is an open standard that connects AI agents to external tools and data through a uniform interface. Its rapid 2025 adoption created an identity problem: agents act as machine identities that need scoped, revocable authorization rather than long-lived shared keys.
When the Model Context Protocol took off in 2025, it solved a real problem: every agent needed a different adapter for every tool, and MCP gave them one interface. But a uniform door to your systems is also a uniform door for attackers. The hard part of MCP is not the protocol — it is identity.
Why does MCP create an identity problem?
An agent connected through MCP acts on your systems. To do that it authenticates — with an API key, a token, a certificate. That makes the agent a non-human identity (NHI), and most organizations have no real management for these. They were built to govern people: joiners, movers, leavers. An agent is none of those, yet it can read a database or send an email.
The result is what practitioners call an identity crisis: thousands of machine credentials, often long-lived, broadly scoped and owned by no one. When an agent is compromised through prompt injection, those credentials are the blast radius.
Authentication is not authorization
A common mistake is to stop at authentication: the agent proves who it is, and then it can do anything that identity can do. That is far too coarse for autonomous systems.
The control that matters is runtime authorization — deciding, at the moment of each action, whether this identity should perform this action right now, given context. A read token should never silently become a write. A tool that summarizes invoices should not be able to issue payments.
| Aspect | Authentication | Authorization |
|---|---|---|
| Question it answers | Who is this identity? | May it do this action, now, in this context? |
| When it runs | Once, at connection | At every sensitive action |
| If you stop here | The identity can do anything its role allows | Each action is checked against policy |
| MCP example | The agent presents a token | The gateway approves a read, denies a payment |
The gateway: one place to ask “should this happen?”
The control point that makes runtime authorization practical is an MCP gateway — a layer between your agents and the MCP servers they call. Instead of every server enforcing its own trust inconsistently, the gateway concentrates four things: scoping (which identity may call which tool, least privilege in one place), runtime policy (rules evaluated at call time, so a read token never silently becomes a write), approval routing (high-impact actions go to a human before they execute) and per-identity audit (one attributable trail instead of fragments across servers).
| Control | With a gateway | Without one |
|---|---|---|
| Scoping | Least privilege enforced in one place | Each server decides, inconsistently |
| Runtime policy | Rules checked at call time | Trust-by-default after login |
| Approval | High-impact actions routed to a human | Wired ad hoc per server, or skipped |
| Audit | One per-identity trail | Fragmented across servers |
For one agent calling one trusted tool, a gateway is ceremony you do not need yet — scope that credential tightly and move on. Add one the moment a wrong action could cause real harm: several agents, third-party MCP servers, or tools that move money or touch production. Three habits keep it governable: express permissions as policy-as-code so they are versioned and testable, default to deny, and route irreversible actions to human approval. It is not an API gateway with a new name — an API gateway guards a service’s front door per request, while an MCP gateway decides, action by action, whether the reasoning agent inside may pull a given lever; in most architectures they coexist.
A practical control stack
- Inventory. List every MCP server and the credentials it holds. Unowned identities are the first thing to fix.
- Least privilege per tool. Scope each credential to the minimum. Prefer short-lived, automatically rotated tokens over static keys.
- Runtime authorization. Put a policy decision in front of sensitive actions — an MCP gateway or authorization layer, not trust-by-default.
- Per-identity audit. Log which identity did what, with signed, tamper-evident records. An action you cannot attribute is an action you cannot govern.
- Zero-trust between agents. In multi-agent systems, one agent must not treat another’s request as automatically safe.
The 30/90/180 view
In the first 30 days, inventory and kill the worst long-lived keys. By 90 days, scope tools to least privilege and add a gateway for sensitive actions. By 180 days, every machine identity has an owner, a lifecycle and an audit trail.
Identity is where agent security and governance meet. Get the vocabulary straight in the glossary, then start with the one thing that always pays off: list what you have.
Frequently asked questions
Is MCP itself insecure?
The protocol is not the core problem — the wiring is. MCP standardises how agents reach tools, so existing authorization mistakes (broad tokens, long-lived keys, over-permissive tools) suddenly scale through one interface. The fix is not abandoning the standard but disciplined authorization: scoped, short-lived credentials, a policy decision before sensitive actions, and an owner plus audit trail for every machine identity.
How is an MCP gateway different from an API gateway?
They share a shape but answer different questions. An API gateway handles HTTP concerns — routing, rate limits, authentication — for clients calling your services, per request. An MCP gateway is built for agent behaviour: fine-grained, per-action authorization for non-human identities calling tools in a loop, plus approval routing and per-identity audit. In most architectures they coexist, each doing the job the other was not designed for.
What should we do first?
Inventory, before anything else. List every MCP server, every agent and every credential each holds, then flag the long-lived, broadly scoped and unowned ones — that is your immediate risk. Kill or rotate the worst static keys, scope the rest to least privilege, and put a runtime check in front of genuinely sensitive actions. Discovery first, containment second.
Why are long-lived API keys so risky for agents?
Duration multiplied by reach. A static key works indefinitely, so a copy leaked through a log, a prompt injection or a compromised dependency stays valid long after the incident — and it usually carries far more access than any one task needs. Replace static keys with short-lived, scoped, automatically rotated tokens and per-identity audit logging, so a stolen credential expires quickly and can be traced.