MCP server authorization gaps expose familiar web app failures

At a glance

What this is: This is a Bishop Fox analysis of how an MCP server can be discovered and abused through direct tool calls, with the key finding being an authorization gap that allowed an unprivileged user to delete another user’s ticket.

Why it matters: It matters because teams securing MCP, agentic AI, and adjacent service APIs still need server-side authz, input validation, and least privilege, or a new interface simply reproduces old access-control failures.

By the numbers:

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

👉 Read Bishop Fox's analysis of MCP server discovery and authorization gaps

Context

Model Context Protocol, or MCP, is an interface layer that lets AI systems connect to tools and data sources. In practice, that means an MCP server can look less like a novel AI construct and more like a remotely reachable application endpoint that still needs normal access control discipline.

The primary governance gap here is not the protocol itself but the assumption that AI-facing tooling can be treated as inherently safer or more insulated than a traditional web service. Once an MCP server is exposed to a network path, the same controls that protect any privileged API become the deciding factor for whether an unprivileged user can cross an authorization boundary.

For identity teams, the implication is straightforward: MCP belongs in the same conversation as API security, service identity, and least-privilege enforcement. Discovery, authentication, authorization, and auditability all matter before agent use or direct tool invocation ever becomes routine.

Key questions

Q: How should security teams secure a remote MCP server?

A: Security teams should place an authentication and authorization layer in front of the MCP server, keep the tool service private where possible, and validate every request before it reaches connected tools. That approach reduces unauthorized invocation, creates a policy point for roles and scopes, and makes tool use attributable in logs.

Q: Why do MCP servers increase the risk of agentic access abuse?

A: MCP servers connect agents to real systems, so a weakly controlled server becomes a privilege bridge rather than a simple integration layer. If authentication, authorisation, and context filtering are loose, a prompt injection or malicious client can turn normal tool access into data exposure or unsafe execution.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role. In practice, that makes audits less reliable and magnifies the blast radius of any compromise or misconfiguration. The fix is narrower claim-based policy, not looser trust in the calling identity.

Q: Who is accountable when an MCP server authorises the wrong action?

A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.

Technical breakdown

MCP server discovery from an attacker’s view

An exposed MCP server can be found the same way many other services are found: network scanning, endpoint fingerprinting, and then protocol-specific validation. In this case, the test path used nmap to identify an open HTTP service and a Nuclei template to confirm MCP-style endpoints such as /mcp and /sse. That matters because the attack surface begins before any tool call, at the point where a service becomes reachable and recognisable on the network. If discovery is easy, every downstream control has to assume hostile probing, not trusted use.

Practical implication: inventory MCP endpoints as exposed services and treat discovery as the first control boundary.

Why direct tool invocation changes the risk model

MCP Inspector was used here to call server tools directly through JSON-RPC rather than relying on an LLM to broker the request. That is important because it removes the illusion that the model layer is the security boundary. The request path still ends at the server, where authorization must be enforced before any privileged action is executed. If the server trusts the caller too early, the tool interface becomes a direct abuse path, regardless of how the request was generated.

Practical implication: enforce server-side authorization on every tool call, even when requests appear to come from controlled client tooling.

Why authorization, not protocol novelty, determines exposure

The critical failure in the example was not exotic exploit logic. The server accepted a delete_ticket action from an unprivileged user because the authorization check was absent or ineffective. That is a standard access-control failure, not a new AI-specific class of defect. For identity and application teams, the lesson is that any tool capable of state change must be bound to a verified identity, explicit scope, and per-action decision point. Otherwise, the protocol only makes old privilege mistakes easier to reach.

Practical implication: map every state-changing MCP tool to an identity, a scope, and an authorization decision before deployment.

Threat narrative

Attacker objective: The attacker’s objective is to use a reachable MCP tool interface to perform privileged actions that should have been blocked by authorization.

1. Entry occurs through network discovery of an exposed MCP server, followed by endpoint fingerprinting to confirm the service accepts protocol traffic.
2. Escalation happens when direct JSON-RPC tool calls are accepted without effective authorization checks, allowing an unprivileged caller to invoke privileged actions.
3. Impact is unauthorized deletion of another user’s ticket, demonstrating that exposed MCP tooling can translate into data integrity loss when server-side controls are weak.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 does not create new security physics, it reuses old web application failure modes. The article’s core lesson is that an MCP server exposed to the network behaves like any other privileged API endpoint when an attacker can reach it directly. That means authentication, authorization, validation, and auditability remain the decisive controls. Practitioners should treat MCP as an application security problem with identity consequences, not as a special-case AI exception.

The named concept here is MCP authorization drift. Once tool endpoints are exposed, teams often assume protocol mediation or client tooling will preserve intent and scope. This example shows that assumption is weak when the server itself does not enforce per-action authorization. The implication is that identity and policy boundaries must live at the server, not in the conversation layer or client workflow.

Discovery risk matters because exposed MCP services are easy to enumerate and validate. A scan plus endpoint fingerprinting was enough to identify a live server in the example, which means obscurity is not a control. For governance programmes, the real issue is that AI-adjacent services can be discovered like any other web service and then tested for privilege flaws at machine speed. Practitioners should assume hostile discovery from the outset.

Least privilege only works when every state-changing tool has a separate decision point. The delete_ticket path failed because the server trusted the caller too much at the moment of execution. That is the same design error identity teams see in over-permissioned service accounts and APIs: the capability exists, but the guardrail is missing where action becomes real. Practitioners should insist on action-level authorization, not just session-level trust.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• Another 53% of MCP servers expose credentials through hard-coded values in configuration files, which makes tool exposure and credential exposure reinforce each other.
• For a broader governance lens, see OWASP NHI Top 10 for how identity and tool abuse converge in agentic environments.

What this signals

MCP authorization drift: teams are likely to keep treating AI tool servers as special cases until a direct abuse path forces them back into standard application security controls. The practical shift is to govern MCP like any other privileged API surface, with explicit scope, auditability, and service ownership. For teams building out control coverage, Ultimate Guide to NHIs , Key Challenges and Risks remains the clearest internal reference point for privilege, visibility, and lifecycle gaps.

The next programme decision is whether MCP servers sit inside the same policy boundary as other service identities or remain an exception handled ad hoc. That distinction affects inventory, recertification, and incident response design more than it affects protocol implementation. If the service can change state, it should be reviewable, attributable, and revocable like any other high-risk non-human identity.

Identity teams should also expect more pressure to align MCP governance with established control frameworks rather than inventing AI-specific exceptions. The relevant discipline is already familiar in NIST Cybersecurity Framework 2.0 and OWASP Agentic AI Top 10: discover assets, constrain privileges, detect abuse, and prove accountability.

For practitioners

• Inventory every exposed MCP endpoint Treat /mcp, /sse, and any similar tool endpoints as externally reachable application surfaces. Put them into the same service inventory, ownership model, and monitoring pipeline you use for privileged APIs and admin consoles.
• Enforce server-side authorization on each tool call Require an explicit authorization decision before any tool can read, modify, or delete state. Do not rely on client tooling, prompt design, or the LLM layer to preserve access boundaries.
• Map state-changing tools to identity scopes Assign each privileged tool to a service identity, a scope, and a logged action class. If a tool can delete, update, or approve records, it needs the same control discipline as a sensitive API route.
• Test MCP services with offensive validation methods Use scanning, endpoint validation, and direct tool invocation tests in pre-production and red-team exercises. The point is to find whether an unprivileged caller can bypass intended role boundaries before the service is exposed broadly.
• Review audit logging for tool-level accountability Log who called which tool, with what arguments, and what state changed. If you cannot reconstruct a delete or edit action from logs, you cannot investigate abuse or certify control effectiveness.

Key takeaways

• MCP servers can be abused like ordinary privileged web services when authorization is weak or missing.
• The article’s example shows that network discovery plus direct tool invocation can turn a simple access gap into unauthorized data deletion.
• Practitioners should govern MCP endpoints with server-side authz, scoped tool permissions, and audit-ready accountability before broad exposure.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.

What's in the full article

Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:

• The exact nmap and Nuclei workflow used to fingerprint the MCP service in a lab environment
• The JSON-RPC request and response structure for direct MCP tool invocation through MCP Inspector
• The specific delete_ticket call pattern that bypassed intended authorization boundaries
• The end-to-end blog series context that connects discovery, interaction, and exploitation paths

👉 The full Bishop Fox post shows the scan, enumeration, and unauthorized ticket deletion path in detail.

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.