MCP security best practices shift control to runtime governance

At a glance

What this is: Apono argues that MCP security must govern the entire trust chain from intent to action, with task-scoped access, server-side authorization, approval for sensitive actions, and full token lifecycle controls.

Why it matters: This matters because MCP-connected agents can reach real systems through tools and credentials, so IAM, PAM, and NHI teams need runtime controls that limit privilege, approval, and revocation beyond authentication alone.

By the numbers:

• Anthropic also reported 97M+ monthly downloads of its Python and TypeScript MCP SDKs by December 2025.

Context

MCP security is the governance problem that appears when a model can turn natural-language intent into tool calls against real systems. The protocol creates a shared way to discover and invoke capabilities, but it does not by itself decide which identities may act, what they may touch, or how long that access should last.

That gap matters most for non-human identity programmes because MCP-connected clients, servers, tools, and downstream resources expand the access chain well beyond a single authentication event. In practice, the control question shifts from whether the agent is signed in to whether the whole action path is authorised, bounded, logged, and revocable.

The article treats public MCP adoption as a production security problem, not a protocol curiosity. That framing is typical of the current market: teams are moving from experimentation to governed runtime access, and the weakest point is often not transport security but overbroad privilege at execution time.

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: Why do task-scoped privileges matter for MCP-connected agents?

A: Task-scoped privileges matter because MCP agents often need access only for a single operation, not a persistent entitlement. If privilege remains standing, the agent carries unnecessary blast radius into later actions, compromised tools, or misrouted requests. Runtime issuance and expiry reduce that exposure materially.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: Should organisations require human approval for all MCP actions?

A: No. Human approval is most valuable for high-risk operations such as destructive changes, large exports, and billing or access modifications. Low-risk read-only tasks can remain automated if the request is tightly scoped and continuously validated. The key is to separate reversible machine tasks from irreversible actions that need accountability.

Technical breakdown

Why MCP authorization must survive beyond authentication

MCP standardizes how a client discovers tools and invokes them, but authentication alone does not say which actions are safe. In an MCP flow, the same identity may list data, call an API, or change infrastructure depending on the tool and resource behind the request. That is why server-side authorization matters: policy must evaluate the caller, the tool, the target resource, and the operation at the point of execution. Client-side prompts and model reasoning are not security boundaries. The practical issue is that capability discovery can be broader than actual permission, so the server has to reassert the boundary on every sensitive call.

Practical implication: Enforce authorization at the tool and resource layer instead of trusting authenticated access to imply permission.

How task-scoped access changes MCP privilege management

MCP-connected agents often need access only for a specific task, yet standing credentials make that access persistent. A task-scoped model replaces broad permanent permissions with just-in-time issuance that exists only for the work being done. This is especially important when an agent may touch production systems, secrets, or administrative APIs through a tool chain. The runtime decision becomes the control point: what was requested, why it is needed, and whether the privilege should disappear as soon as the task completes. Zero Standing Privilege is the governance pattern that fits this model because it assumes access should not persist by default.

Practical implication: Shift privileged MCP access from provisioning-time grants to runtime issuance and automatic expiry.

Why tokens, tool content, and third-party servers are part of the trust chain

MCP extends the attack surface into token handling, tool metadata, retrieved content, and third-party servers. If a token is stolen, the downstream system often treats it as proof of authority, so lifecycle controls become as important as initial issuance. Likewise, a hostile tool description, poisoned output, or compromised local server can influence what the agent does next, which means input and output must be treated as untrusted until validated. For local or third-party servers, the key risk is that code executing inside a host environment may already have access to files, environment variables, or cached credentials. The trust chain is only as strong as its weakest component.

Practical implication: Treat tokens, tool payloads, and external servers as governed assets with validation, revocation, and isolation controls.

Threat narrative

Attacker objective: The objective is to convert a trusted MCP action path into unauthorized access, data exposure, or infrastructure change through overbroad privileges and weak runtime controls.

1. Entry begins when an MCP-connected agent or client reaches a tool or server that can touch sensitive downstream resources through legitimate protocol access.
2. Credential access or abuse occurs when standing credentials, overly broad tokens, or token passthrough let the caller inherit more privilege than the task requires.
3. Escalation follows when server-side checks are missing, allowing the same session to move from harmless tool use to destructive or data-bearing actions.
4. Impact is the unauthorized query, modification, deployment, or exposure of downstream systems before the organisation can revoke access or stop the workflow.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

NHI Mgmt Group analysis

Runtime governance is now the real control plane for MCP. Authentication tells you who connected, but it does not control what a connected agent can do next. Once a model can invoke tools that reach data, infrastructure, or administrative APIs, the security decision moves to execution time and must be re-evaluated on every action.

Task-scoped privilege is the only defensible answer to MCP sprawl. Standing permissions assume the actor needs broad access before the task begins, which is exactly the wrong model for tool-mediated actions. The practical implication is that identity and privilege decisions must be bound to intent, task, and resource at runtime rather than inherited from a generic login event.

Full trust-chain inventory is the named gap: invisible MCP surfaces create invisible blast radius. The article's core governance assumption is that teams know which clients, servers, tools, owners, and backend identities exist. That assumption fails when local servers, third-party packages, and hidden downstream resources are added ad hoc, so the real issue is not merely tool approval but ownership and reachability visibility.

Token lifecycle is part of identity governance, not a separate hygiene task. MCP turns token storage, scope, revocation, and log hygiene into first-class control points because the token is the practical proof of access at the downstream system. If revocation is slow or incomplete, the trust chain survives long after the task should have ended, which makes lifecycle discipline a governance requirement.

Human approval should be selective, not universal. Sensitive actions such as deleting production assets, exposing data, or granting elevated access need an approval gate, but routine actions do not. That distinction matters because MCP programmes fail when every action is treated as manual, yet they also fail when high-risk actions are allowed to self-authorize through model behavior alone.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Runtime governance is the category shift: MCP programmes should be designed around what an agent can do at execution time, not around the fact that it authenticated successfully. That means policy, approval, and revocation all need to sit at the point where the tool call becomes real.

The practical shift for identity teams is that access reviews alone are not enough when tools, servers, and tokens can create a much larger live permission set than the original login suggests. Inventory, task-scoping, and selective approval become the controls that keep the trust chain intelligible.

For practitioners

• Map the full MCP trust chain Inventory every approved client, server, tool, owner, backend identity, and downstream resource, including locally installed components that developers add outside central procurement.
• Move privileged access to runtime Replace standing permissions with task-scoped, short-lived access so MCP-connected agents receive only the privileges required for the current action.
• Enforce server-side authorization checks Validate the requesting identity, target resource, requested operation, and context at the point of execution rather than relying on authentication or client instructions.
• Treat tokens and tool content as untrusted Store secrets securely, validate tool arguments and outputs, and revoke or rotate credentials quickly if a token, server, or retrieved payload is compromised.
• Test revocation and containment paths Run an incident exercise that proves you can disable a compromised server, block high-risk tools, and terminate temporary as well as persistent access without guesswork.

Key takeaways

• MCP security expands identity governance from login events to the full chain of tools, servers, credentials, and downstream systems.
• The operational risk is not limited to authentication failure, because standing privilege and weak revocation let connected agents act far beyond their intended scope.
• Runtime authorization, short-lived access, and selective human approval are the controls that reduce blast radius without forcing every action into manual review.

Key terms

• MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
• 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.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Token Lifecycle: Token lifecycle is the full sequence of issuing, refreshing, expiring, revoking, and reauthorizing a credential. For delegated access, lifecycle state is the real indicator of whether a connection is still legitimate, because a valid-looking token can still be stale, disconnected, or out of scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.