Notifications
Clear all
Topic starter
16/09/2026 9:21 am
TL;DR: MCP security now depends on governing the full trust chain, not just authentication, as Apono argues that server-side authorization, task-scoped access, human approval, and lifecycle token controls are required while Anthropic reported more than 10,000 active public MCP servers and 97M+ SDK downloads by December 2025. The practical break point is the assumption that a model can safely choose and execute privileged actions without runtime identity controls.
NHIMG editorial — based on content published by Apono: 10 MCP Security Best Practices
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.
Questions worth separating out
Q: What breaks when MCP servers do not require authentication?
A: When MCP servers do not require authentication, the access boundary disappears.
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.
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.
Practitioner guidance
- 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.
- Enforce server-side authorization at execution time Check the requesting identity, target resource, requested operation, and context where the tool action is actually executed.
- 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.
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
👉 Read Apono's 10 MCP security best practices for identity and runtime control →
MCP security best practices: are your controls keeping up?
Explore further
16/09/2026 9:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security best practices shift control to runtime governance
