MCP security.
The Model Context Protocol (MCP) lets AI agents connect to external tools and data through a standard interface. MCP security is the practice of controlling what an agent can actually do through those connections — authenticating the agent, authorizing each individual tool call, scoping and vaulting the underlying credentials, and auditing every action. It matters because an MCP server effectively hands an autonomous, model-driven agent the keys to whatever it connects to, and the agent decides what to call at runtime.
Key takeaways
- MCP hands an autonomous agent access to your tools; security means controlling what it can actually do.
- OAuth authenticates the agent but does not authorize each tool call — you need both.
- Core risks: over-broad scopes, standing credentials, confused deputy, and prompt-injection → tool abuse.
- Defend at the authorization layer: per-call policy, zero standing privileges, a gateway, and audit logging.
MCP authentication vs MCP authorization.
| Dimension | MCP authentication | MCP authorization |
|---|---|---|
| Answers | Which agent/client is this? | May this agent make THIS tool call now? |
| Mechanism | OAuth 2.1, PKCE, token exchange | Per-tool-call policy (RBAC/ReBAC/ABAC), scopes |
| Granularity | Per connection / session | Per action, per resource, per request |
| Failure mode if skipped | Unidentified or spoofed clients | Confused-deputy + prompt-injection → tool abuse |
| Enough on its own? | No — identifies, does not constrain | This is where real control lives |
Why MCP is a new attack surface
MCP standardizes how an agent reaches tools, files, databases, and SaaS APIs. That convenience is also the risk: a single MCP connection can expose a broad set of high-impact actions to an identity whose next move is decided by a language model, not a fixed script. The agent’s behavior is influenced by untrusted input (documents, web pages, tool outputs), so an attacker who can inject instructions can try to steer the agent into calling tools it shouldn’t.
The core risks
Most MCP incidents reduce to a handful of patterns:
- Over-broad scopes — the MCP server is wired to a credential that can do far more than the task needs.
- Standing credentials — long-lived tokens the agent holds even when idle, so a compromise is always live.
- Confused deputy — the agent is tricked into using its legitimate access on an attacker’s behalf.
- Prompt injection → tool abuse — malicious input in the context steers the model into harmful tool calls.
- No per-call authorization — once connected, the agent can call anything the server exposes.
How to secure MCP
Authentication identifies the agent; it does not constrain it. Real MCP security is authorization and credential hygiene enforced at the tool-call layer:
- Authenticate agents with OAuth 2.1 (PKCE, resource indicators, token exchange) — see "OAuth 2.1 for AI agents".
- Authorize every tool call against policy (RBAC/ReBAC/ABAC), not just at connection time.
- Apply zero standing privileges — vault the real credentials and issue ephemeral, downscoped access per task.
- Put a gateway in front of the MCP server to enforce policy, consent, and rate limits centrally.
- Log every tool call with the human + agent + intent so actions are auditable and reconstructable.
Common questions.
Is OAuth enough to secure MCP?+
No. OAuth 2.1 is the right foundation for authenticating the agent and establishing a session, but it answers "who is this client?" — not "may this client make this specific tool call right now?" That per-action decision is authorization, and it needs a policy layer (RBAC/ReBAC/ABAC) enforced at the tool-call level.
What is an MCP gateway?+
An MCP gateway sits between agents and MCP servers and enforces identity, fine-grained authorization, consent, audit logging, and rate limiting centrally — so policy is not reimplemented in every server. It is the practical place to apply zero standing privileges and per-tool-call authorization.
How do you stop prompt injection from abusing tools?+
You cannot fully prevent a model from being steered by malicious input, so you constrain what a steered agent can do: least-privilege scopes, per-tool-call authorization, zero standing privileges, human-in-the-loop confirmation for high-impact actions, and audit logging. Defense is at the authorization layer, not the prompt.
The whole picture, in one place.
This explainer is part of our complete guide to IAM — authentication, authorization, governance, privileged access, the standards, and how to run a program.