MCP security best practices shift control to runtime governance

At a glance

What this is: This is a practitioner guide to MCP security that argues protection must cover identities, permissions, tools, tokens, and downstream systems, with runtime authorization and scoped access doing the real work.

Why it matters: It matters because IAM teams now have to govern agent-driven action paths, not just human sign-in events, and the same control failures can expose NHI, autonomous, and human identity programmes to overreach and privilege abuse.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Apono's 10 MCP security best practices for identity and runtime control

Context

MCP security is the discipline of governing the trust chain that connects intent to action. In practice that means the security boundary now extends from the user or agent through the client, server, tool, and backend resource, which makes identity and authorization controls more important than the protocol wrapper alone. For MCP server security, the failure mode is usually not a broken connection, but a trusted action that reaches too far.

That shift matters for NHI governance because MCP-connected systems often rely on credentials, tokens, and service identities that behave like any other non-human identity, except they are invoked dynamically by agents or clients. Traditional authentication confirms who connected, but it does not by itself prove what tool should be called, which resource should be reached, or how long privilege should last. The governance problem is therefore runtime access scope, not just login assurance.

The article also places the topic in a production context, not an experimental one. Once agents can trigger real API calls, query sensitive data, deploy code, or modify infrastructure, the old assumption that access can be granted broadly and cleaned up later no longer holds.

Key questions

Q: What breaks when MCP servers do not require authentication?

A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.

Q: When should teams prioritise task-scoped access over standing credentials for MCP?

A: Teams should prioritise task-scoped access whenever an MCP-connected actor can reach production systems, sensitive data, or privileged APIs. Standing credentials create an unnecessary blast radius because the agent may never need all of that access at once. JIT access is the right choice when the business can tolerate runtime gating in exchange for less persistent privilege.

Q: What do security teams get wrong about token protection in MCP environments?

A: The common mistake is treating token storage as the whole problem. Token protection also includes audience scoping, refresh-token rotation, revocation, log hygiene, and cache removal. If a stolen token still works downstream, the attacker inherits the same access the backend system intended for the legitimate caller.

Q: How should security teams handle approval for high-risk MCP actions?

A: Approval should be reserved for actions that are irreversible, high impact, or likely to change access, data exposure, or production state. The goal is not to slow every task, but to stop the few actions that create real business risk if executed incorrectly. Approval should occur before the sensitive permission is granted or the action executes.

Technical breakdown

MCP security and the trust chain from intent to backend action

MCP standardizes tool discovery and invocation, but it does not replace enterprise authorization. The trust chain includes the actor, client, server, tool, and backend system, and a weakness in any one layer can widen what the agent can do. The important distinction is between authentication and authorization: authentication proves the caller is known, while authorization proves the specific action is allowed in context. In remote deployments, the server must validate audience-bound tokens, while local servers inherit host risk and therefore need a different control model.

Practical implication: govern MCP as an end-to-end access path, not as a simple protocol integration.

Task-scoped access, JIT access, and Zero Standing Privilege for MCP

Standing credentials are the wrong default for MCP-connected agents because privilege is often needed only for a single task. Just-in-time and just-enough access reduce the blast radius by granting permissions only when required, limiting them to specific resources and actions, and revoking them when work finishes. Zero Standing Privilege is the operational expression of that model. It matters because the agent may be compromised, misdirected, or given the wrong instruction, and broad pre-existing access turns a local mistake into a systemic incident.

Practical implication: replace broad long-lived permissions with runtime-scoped privileges and explicit revocation.

Server-side authorization and token lifecycle protection in MCP

MCP tools are not security boundaries by themselves. Authorization has to survive tool discovery, and it has to be enforced at the point where the action is actually executed. That includes validating the requesting identity, target resource, operation, and context, then binding state handles to the verified principal rather than treating possession as proof. Token and secret protection must cover storage, transmission, audience scoping, refresh-token rotation, revocation, log hygiene, and cache removal because a stolen token inherits whatever downstream access the system grants.

Practical implication: move policy enforcement and token control into the server and lifecycle layers, not the client prompt.

Threat narrative

Attacker objective: The objective is to turn a trusted MCP action path into unauthorized access, data exposure, or infrastructure change with minimal friction.

1. Entry occurs when a compromised or untrusted MCP server, client, or retrieved content influences a tool invocation and pushes a real action path into motion.
2. Escalation follows when standing credentials, permissive tool access, or weak server-side checks allow the action to reach sensitive data, infrastructure, or privileged APIs.
3. Impact lands when the token, tool, or workflow is used to modify systems, exfiltrate data, or keep access alive beyond the intended task boundary.

Breaches seen in the wild

• Indian Government Breach — Indian government systems breach exposes sensitive credentials and citizen data.
• United Nations Breach — Ethical hackers discover United Nations systems exposed via GitLab credential misconfiguration.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is really identity security with a different interface: the protocol does not remove the need to decide who or what may act, what it may touch, and how long that access should last. The article is right to shift attention away from authentication alone and toward tool permissions, credentials, and downstream resource scope. For practitioners, that means MCP needs the same governance discipline applied to other non-human identities, only with tighter runtime controls.

Task-scoped access is the correct default because MCP actions are intent-driven, not session-stable: the article's Zero Standing Privilege framing is the practical centre of gravity. Broad standing access turns agent mistakes, indirect prompt injection, or server compromise into immediate blast-radius events. The governance lesson is that persistent privilege is now a category error for production MCP use.

Server-side authorization is where MCP security either works or fails: the article correctly rejects the idea that tool exposure or model behaviour can stand in for policy. A user or agent may be known, but that does not mean the specific tool, resource, or operation is allowed. The named concept here is runtime governance gap: the point where a trusted invocation path still lacks policy at execution time, which is where abuse becomes possible.

Token lifecycle is now a containment problem, not just a storage problem: short-lived credentials reduce exposure, but revocation, invalidation, and log hygiene determine whether compromise remains local or becomes persistent. MCP teams should treat every exposed token as a downstream authorisation problem, because the access the token confers is whatever the backend system decides it means. That is why lifecycle controls belong in the same governance conversation as inventory and approval.

Human approval still has a role, but only for irreversible or high-risk actions: the article is strongest when it separates routine automation from actions that change access, data exposure, or production state. That distinction matters across human, NHI, and autonomous programmes because approval gates are about consequence, not about whether the actor is a person or an agent. The practitioner takeaway is to reserve escalation for impact, not for every invocation.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security's The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security's The State of MCP Server Security 2025.
• For adjacent AI agent governance, read our AI agents attack-surface research to see how scope drift and audit gaps compound once agents start acting independently.

What this signals

Runtime authorisation is becoming the deciding control for MCP programmes: if access scoping is missing, the platform is effectively asking agents to operate with implicit trust. That is a poor fit for production identity governance, especially where tools can reach cloud control planes, databases, or administrative APIs. The practical shift is toward policy at execution time, not after the fact, and the closer this gets to the OWASP Non-Human Identity Top 10, the clearer the control pattern becomes.

Identity teams should treat MCP as a lifecycle problem, not a deployment problem: inventory, ownership, approvals, revocation, and auditability all matter because the same credential can outlive the task that justified it. Once a server, tool, or token is unowned, the governance gap is no longer technical only. It becomes a control assurance issue that spans IAM, PAM, and NHI operations.

Ephemeral access will matter more as agent adoption expands: if the environment is already showing thousands of public MCP servers and large SDK uptake, the scale pressure is obvious. The programme response is to reduce standing privilege, formalise approval paths for sensitive actions, and tie runtime traces back to specific identities and resources so that incident containment remains possible.

For practitioners

• Inventory every MCP component and owner Maintain a live inventory of MCP clients, servers, tools, backend identities, and downstream resources, then classify which ones can reach production systems or sensitive data. Use the inventory to drive access reviews and incident response.
• Enforce server-side authorization at execution time Check the requesting identity, target resource, requested operation, and context where the tool action is actually executed. Do not let client instructions or tool descriptions act as a policy boundary.
• Replace standing permissions with task-scoped access Grant just-in-time, just-enough access for a specific MCP task, then revoke it immediately after completion. Keep elevated permissions out of the default state for agents and connected servers.
• Protect tokens through the full lifecycle Store tokens securely, scope them to the correct audience, rotate refresh tokens, invalidate exposed credentials, and remove secrets from logs and caches. Test revocation so compromised access can be terminated without delay.
• Require approval for irreversible actions Route destructive or high-impact actions such as deleting production resources, changing access policies, or exposing sensitive data through a human approval step before the action executes.

Key takeaways

• MCP security fails when teams stop at authentication and ignore runtime authorisation, tool scope, and token lifecycle controls.
• The strongest available evidence points to a large deployment gap, with only 18% of MCP servers scoping tool permissions and 24,008 exposed secrets in 2025.
• Practitioners should move to task-scoped access, server-side policy enforcement, and revocation-ready incident processes before agent use expands further.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Server-side authorization: The practice of deciding access on the backend where an action actually executes. It prevents direct endpoint calls from bypassing UI checks and is the only place where an application can reliably stop an unauthorised mutation or data read before it happens.

What's in the full article

Apono's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for inventorying MCP clients, servers, tools, owners, credentials, and backend identities
• Practical authorization patterns for remote MCP, including audience-bound tokens and PKCE protection
• Runtime privilege and approval workflows for sensitive actions such as deleting resources or changing access policies
• Token lifecycle handling, including revocation, invalidation, and log hygiene when access is compromised

👉 Apono's full article covers the inventory, authorization, approval, and token lifecycle detail behind MCP security.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.