MCP server security best practices are becoming identity controls

At a glance

What this is: This is an analysis of MCP server security best practices, with the key finding that rapid adoption is outpacing identity controls and leaving many servers exposed through weak authentication, overscoping, and permissive defaults.

Why it matters: It matters because MCP is becoming a live identity boundary for AI agents, so IAM, NHI, and PAM teams need to govern authentication, consent, and tool scope before those servers become routine access paths.

By the numbers:

• Knostic researchers scanned nearly 2,000 publicly accessible MCP servers and found that every single verified instance granted access to internal tool listings without any authentication.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Descope's MCP server security best practices for agent-led access

Context

MCP server security is the governance problem that appears when AI tools need to reach enterprise data and actions through an identity layer. The technical issue is not the protocol itself but the way teams expose tools, tokens, and permissions before they have a stable control model for authentication, consent, and least privilege.

That gap matters because MCP sits directly in the path between agent requests and real systems of record. Once a server becomes the access broker for email, documents, code, or business apps, security teams are no longer just protecting an API. They are governing a new identity surface that behaves like an NHI control plane for agentic access.

The article’s central warning is that developers are adopting MCP faster than identity controls are being adapted to it. That is typical for a fast-moving platform shift, but it is also exactly how overscoping and default trust become normalised in production.

Key questions

Q: How should security teams govern MCP servers in production?

A: They should govern MCP servers as identity-sensitive access infrastructure, not as ordinary application endpoints. That means separating authorization from the resource server, enforcing OAuth 2.1 and PKCE, binding tokens to specific resources, and scoping each tool separately. The control objective is to prevent one agent session from turning into broad, reusable enterprise access.

Q: Why do MCP servers create new identity risks for enterprise IAM?

A: MCP servers sit between agents and real business systems, so they inherit authentication, consent, and privilege problems in a much tighter runtime loop. If teams rely on the model to police behaviour, overscoping and prompt injection can turn delegated access into unauthorized action. IAM teams need to treat the protocol as a governed access path, not a chatbot integration.

Q: What breaks when MCP tools are overprivileged?

A: A single agent session can move from one low-risk action to multiple high-risk actions across different services without fresh review. That breaks least privilege, weakens audit trails, and makes containment harder if the session is misused. The practical failure is not just excess access, but excess access that spans tools and becomes difficult to unwind cleanly.

Q: Who is accountable when an MCP agent takes the wrong action?

A: Accountability rests with the organisation that defined the policy, the consent model, and the delegated scope, not with the protocol itself. If an agent acts outside the intended boundary, investigators need to trace which identity issued the token, which tools were exposed, and which control failed to limit the action. Governance evidence matters as much as technical logs.

Technical breakdown

OAuth 2.1 and PKCE are the base identity layer for MCP

For remote MCP servers, authentication and token handling should be treated as a standard OAuth problem, not an AI-specific exception. OAuth 2.1, PKCE, resource indicators, and protected resource metadata define how a client proves itself, receives tokens, and binds those tokens to the right server. The important design point is separation of duties: the resource server should validate and enforce, while the authorization server issues and governs credentials. When teams blur those roles, auditability drops and token misuse becomes harder to contain.

Practical implication: keep authorization separate from the MCP resource layer and bind tokens to specific resources.

Consent and scope are the real control points in agent-led access

MCP changes the interaction model because the agent is the active requester even when the human is the principal behind it. That breaks the old assumption that users can see every action as it happens. Consent therefore has to describe tool access, data exposure, and duration in a way that is understandable before the session starts. Short-lived, task-scoped access is more defensible than broad standing access, especially when the agent can chain requests across multiple tools inside one workflow.

Practical implication: scope MCP consent to the task and make access expire when the task ends.

Tool-level authorization must prevent overscoping across services

MCP servers often aggregate many tools, but each tool can carry very different risk. Read access to a calendar should not imply write access to a CRM, and access to one internal API should not automatically extend to another. Scope-based authorization therefore has to operate at the tool level, with progressive scoping used only when a later task genuinely requires more privilege. Without that structure, a single compromised or misbehaving session can move from harmless lookup to cross-system action very quickly.

Practical implication: enforce least privilege per tool and add scopes only when a new task requires them.

NHI Mgmt Group analysis

MCP security is really a governance problem, not just a protocol problem. The article shows that the critical failure point is not whether MCP can be authenticated, but whether teams have identity controls ready before tool exposure becomes routine. The protocol is moving toward clearer security guidance, yet implementation still depends on mature IAM, consent, and access scope design. Practitioners should treat MCP as a production identity boundary, not an experimental integration layer.

Overscoped tool access is the named risk pattern that should anchor MCP governance. The article repeatedly shows that excessive permissions, blanket trust, and model-level policing fail once an agent can request multiple tools in sequence. That is the same control failure pattern identity teams already see in NHI programs when standing privilege is granted too early. The practitioner conclusion is that tool scope, not model sophistication, is the control variable that matters most.

Consent must be treated as an access control event, not a user-experience screen. When an agent acts on behalf of a person, the human is often too far removed from the actual data and action path to rely on intuitive awareness alone. That means consent design has to be precise about what the agent can read, write, and retain, and for how long. Security teams should assume consent quality affects both breach containment and audit defensibility.

Identity teams need to reclassify MCP servers as shared access infrastructure. The server is not just an application endpoint. It becomes the policy enforcement point through which multiple tools, identities, and delegated actions flow. That places MCP in the same governance conversation as privileged access, workload identity, and access lifecycle management. Practitioners should expect MCP to pull IAM, NHI, and app teams into the same operating model.

Runtime scoping will become the dividing line between safe pilots and unsafe production deployments. The article’s architecture guidance points toward a future where static permissions are too blunt for agent-led workflows. As tool portfolios grow, teams will need per-task controls, explicit consent renewal, and traceable identity context across sessions. The practical conclusion is that deployments without runtime scope discipline will accumulate hidden privilege faster than they can be reviewed.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• For a deeper control model, see OWASP Agentic Applications Top 10 for the identity and tool-use risks that accompany agent-led access.

What this signals

Overscoped MCP access will force identity teams to move from static approvals to runtime governance. Once agents can request tools dynamically, the old assumption that access can be safely certified after the fact no longer holds. The programme implication is clear: token scope, consent expiry, and tool-level authorization must be visible in the same operational view as privileged access and workload identity.

With 98% of companies planning to deploy even more AI agents within the next 12 months, according to the AI Agents: The New Attack Surface report, MCP governance will stop being a niche integration concern and start behaving like a mainstream identity architecture issue.

For teams aligning to external control models, the OWASP Top 10 for Agentic Applications 2026 is the right reference point for tool misuse, privilege abuse, and agent boundary failures.

For practitioners

• Separate authorization from MCP resource handling Keep token issuance, client registration, and policy enforcement in a dedicated authorization layer so the MCP server only validates access and serves tools.
• Bind tokens to the exact MCP server and tool set Use resource indicators and tool-specific scopes so a token issued for one server or task cannot be replayed against another server or broader workflow.
• Make consent task-scoped and time-bound Show users which tools, datasets, and actions an agent can access, then expire that permission when the task is complete rather than leaving it open-ended.
• Review tool mappings for overscoping Check whether read access, write access, and admin actions are separated per tool, and remove any default permissions that let one integration inherit broad access across systems.

Key takeaways

• MCP server risk is fundamentally an identity problem because the server becomes the policy gate for delegated agent access.
• The strongest evidence in the article is that overscoping, weak authentication, and permissive defaults are already common enough to be treated as production governance failures.
• Practitioners should separate authorization, constrain scope per tool, and make consent task-bound before MCP usage scales further.

Key terms

• Model Context Protocol: A standard that lets AI clients connect to external tools and data sources through a common interface. In identity terms, it creates a delegated access path that must be authenticated, scoped, and audited like any other production control plane.
• Consent Management: The process of showing a user what an agent is allowed to do, for how long, and against which systems. In MCP environments, consent is not just a legal formality. It is a control that limits delegated access and creates accountability for agent actions.
• Progressive Scoping: A pattern where an agent starts with minimal permissions and requests more access only when a later task genuinely requires it. This reduces standing privilege, improves auditability, and makes it easier to see when an agent’s access is expanding beyond its original boundary.

What's in the full article

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

• Step-by-step explanations of OAuth 2.1, PKCE, and protected resource metadata for MCP deployments.
• Configuration guidance for client registration methods, including CIMD and dynamic registration.
• Example consent flows and scope-binding patterns for agent-led access across multiple tools.
• Deployment notes on how Descope's Agentic Identity Hub maps to MCP authentication and lifecycle management.

👉 Descope's full post covers the OAuth, consent, and scope-control details behind MCP server security.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.