MCP Tools Need Action-Level Authorization

On May 17, 2026, NVD published CVE-2026-8719 for AI Engine 3.4.9, a WordPress plugin that exposes AI and MCP features to WordPress sites.¹³

The failure mode should make every MCP builder uncomfortable. Wordfence described a missing WordPress capability check in the MCP OAuth bearer-token authorization path: any valid OAuth token could reach admin-level MCP tools without verifying administrator privileges.² Wordfence rated the issue 8.8 High and marked version 3.5.0 as the patched release.² The plugin changelog says version 3.5.0 fixed MCP OAuth authorization and token validation by requiring administrator capability.³

MCP authorization fails when a server treats possession of a bearer token as permission to use every tool. OAuth can prove that a token arrived through an authorization flow. The MCP server still has to decide whether that subject may run that tool, on that resource, with that blast radius.

TL;DR

MCP’s HTTP authorization specification gives builders a necessary foundation: protected resource metadata, OAuth 2.1 flows, bearer-token handling, token validation, audience checks, and explicit 403 Forbidden responses for insufficient scopes or permissions.⁴ The MCP security tutorial frames authorization as the protection layer for sensitive resources and operations exposed by MCP servers.⁵ Those mechanics do not remove the application-level authorization decision. A server still has to map the token to a user, role, tenant, tool, resource, action, and policy.

CVE-2026-8719 turns that distinction into a concrete failure. AI Engine added OAuth 2.1 and Dynamic Client Registration for its MCP server in version 3.4.9 on May 12, then patched MCP OAuth authorization and token validation in version 3.5.0 on May 16 by requiring administrator capability.³ The lesson reaches beyond WordPress: every MCP server that can mutate data, publish content, change settings, read private records, spend money, or call privileged APIs needs action-level authorization below the model and below the client.

Tool distribution increases the risk. A May 2026 tool-cloning paper measured 8,861 MCP and Skills repositories with 100,011 tool entries and found high verified clone rates in high-similarity buckets.⁶ Reused templates can spread good patterns. They can also spread missing checks.

Key Takeaways

For MCP server builders: - Validate tokens, then authorize the concrete action. Treat those as separate gates. - Return 401 for invalid or missing tokens and 403 for valid tokens that lack scope or permission. - Test low-privilege tokens against every admin, write, publish, delete, export, and configuration tool.

For security teams: - Review MCP servers like application endpoints, not chat plugins. - Ask which user, role, tenant, resource, and action each tool call maps to. - Require logs that show token subject, tool name, resource, authorization verdict, and denial reason.

For agent-platform teams: - Marketplace counts do not prove independent implementations. - Similarity and provenance checks matter because cloned tools can copy vulnerable authorization logic. - Treat server templates as security-sensitive infrastructure.

For operators: - Upgrade AI Engine to 3.5.0 or later if you run the affected WordPress plugin.²³ - Disable MCP exposure until you know which WordPress roles can reach which tools. - Start every new MCP connection in read-only mode, then widen authority only after tests prove the denial paths.

What Broke In AI Engine

AI Engine markets MCP as a way to connect Claude Code, Claude, ChatGPT, OpenClaw, and other clients to a WordPress site through a URL, sign-in flow, and approval step.³ Version 3.4.9 added OAuth 2.1 with Dynamic Client Registration for the MCP server so browser-driven clients could connect without a shared bearer token.³

That product direction makes sense. Shared static tokens do not fit user-facing MCP integrations. OAuth flows can bind a client, a user, and a server more cleanly than copy-pasted secrets.

The bug sat one layer lower. According to NVD and Wordfence, the vulnerable path accepted any valid OAuth token for MCP access without verifying administrator privilege before granting admin-level MCP tool access.¹² The distinction matters:

The patch description on the WordPress plugin page uses the right language: MCP OAuth authorization and token validation now require administrator capability, preventing privilege escalation by non-admin users.³ That sentence names the missing layer. A token cannot stand in for a capability check.

OAuth Is Necessary, Not Sufficient

MCP’s authorization spec covers the transport-level flow for HTTP-based transports. The spec says MCP clients make requests to restricted MCP servers on behalf of resource owners, and it anchors the flow in OAuth 2.1, protected resource metadata, authorization server metadata, Dynamic Client Registration, and bearer-token usage.⁴

Those pieces solve real problems:

The MCP spec also warns about confused-deputy and token-passthrough risks. MCP servers must validate that presented tokens target the MCP server and must not pass through a token received from the MCP client to upstream APIs.⁴ That guidance protects the boundary between services.

Action-level authorization protects the boundary inside the MCP server.

An MCP server may expose 10 tools or 100. Some tools read public metadata. Some read private records. Some draft changes. Some mutate production state. Some administer users, plugins, payments, jobs, messages, or infrastructure. A valid token should not automatically reach every tool because the server accepted the session.

The correct chain looks like this:

1. Validate token issuer, signature, expiry, audience, and transport rules.
2. Resolve the token to a local subject: user, service account, organization, tenant, or automation.
3. Load that subject’s role, scopes, grants, budgets, and policy.
4. Classify the requested MCP tool by action type and risk.
5. Check the target resource, not only the tool name.
6. Return 403 when the token is valid but the action exceeds authority.
7. Log the decision with enough detail for review.

OAuth gets the request to the decision point. Authorization decides whether the action belongs.

Tool Calls Need A Permission Matrix

Agent tools make old endpoint habits more dangerous. A normal web route often has a narrow UI path around it. A model-facing tool sits inside a planner. The agent can retry, chain calls, inspect tool descriptions, combine read results with write actions, and carry instructions from untrusted content into later steps.

That behavior changes the minimum permission model. A server should not only ask “can this user access MCP?” The server should ask “can this user perform this action through this tool against this resource right now?”

Use a matrix:

That matrix fits the pattern from Agent Keys Need Risk Budgets. Credentials should not behave like all-purpose bearer strings. They should behave like bounded authority objects with server-side limits, activity logs, revocation, and conservative defaults.

It also fits the ownership frame in AI Agent Ownership Is the Trust Primitive. Every privileged tool call should map to a responsible account, session, authority bundle, review path, and stop path.

Cloned Tools Can Copy The Same Missing Check

The AI Engine bug would matter even if every MCP server came from a careful independent implementation. The tool ecosystem does not look that clean.

Kim, Jiang, Hu, Jia, and Gong published a May 10, 2026 paper measuring tool cloning in agentic-AI ecosystems. Their dataset covered 7,508 MCP repositories with 87,564 extracted tools and 1,353 Skills repositories with 12,447 tools, for 8,861 repositories and 100,011 tool entries.⁶ The authors used token-level Jaccard similarity and ssdeep fuzzy structural similarity, then manually verified sampled pairs across similarity buckets.⁶

Their abstract reports that 60% of high-Jaccard candidates and 85% of high-ssdeep candidates in the MCP ecosystem were manually verified as clones.⁶ The paper argues that hidden duplication can contaminate benchmark splits, propagate vulnerable implementations, bias measurements of tool-use generalization, and raise provenance, attribution, and license concerns.⁶

That finding changes how teams should read MCP marketplace growth. More tools do not automatically mean more independent security review. A repeated server scaffold can give the ecosystem consistency. The same repetition can copy the same weak auth pattern across many packages.

The security review should therefore include provenance:

Agent Skills Need Package Managers argued for package-style distribution, provenance, and policy around skills. MCP servers need the same discipline, plus runtime authorization tests.

The Minimum Test Suite For MCP Authorization

Every MCP server that touches private or mutable data should ship an authorization test suite. Unit tests that confirm the happy path do not suffice. The dangerous behavior lives in the denial paths.

Start with these cases:

The exact status code can follow a product’s policy, but the distinction should remain: invalid credentials fail before subject resolution, and valid credentials with insufficient authority fail at the authorization gate. MCP’s spec names 401 for missing or invalid authorization and 403 for invalid scopes or insufficient permissions.⁴

For WordPress specifically, the same rule becomes sharper: MCP tools that perform admin operations should check the same WordPress capabilities that the dashboard, REST API, or internal PHP path would check. A lower-privilege role should not gain a new path to admin behavior because the call arrived through a model-facing protocol.

What Marketplace Review Should Require

MCP marketplaces and plugin directories should treat authorization metadata as first-class package data. A user deciding whether to enable a server needs more than a tool count.

Minimum public metadata:

Those fields would not eliminate vulnerable tools. They would make the review surface real. Operators could compare declared authority against actual code, and marketplaces could group similar implementations when a defect appears.

That is the missing bridge between the MCP authorization spec and the tool-cloning paper. The spec tells implementers how to do the protocol-level flow. The ecosystem needs package-level provenance and action-level authorization evidence so repeated implementations do not repeat the same missing checks.

What To Build Instead

Build MCP authorization as a pipeline:

1. Protocol gate: verify protected resource metadata, OAuth flow, token placement, token validity, expiry, issuer, and audience.
2. Subject gate: map the token to a user, service account, role, tenant, and workspace.
3. Tool gate: classify every tool by read, draft, write, delete, publish, export, admin, execute, or spend.
4. Resource gate: authorize the exact target object or tenant boundary.
5. Budget gate: apply rate, size, spend, audience, and time limits before execution.
6. Approval gate: require human or policy approval for high-risk actions.
7. Audit gate: record allow, deny, and review-required verdicts in a place operators can inspect.

The gates should sit outside the model. A tool description can tell the agent to avoid admin actions. A prompt can ask for caution. Neither should carry the boundary. The server should reject unauthorized action even when the agent asks politely, confidently, or repeatedly.

Your Agent Sandbox Is A Suggestion makes the same point from another angle: valid permissions can still compose into unsafe behavior. MCP tools need authorization at the action boundary because the agent will compose actions faster than a human can mentally simulate them.

FAQ

Does MCP require OAuth?

No. MCP authorization is optional, and the HTTP authorization specification applies when an implementation supports authorization over HTTP-based transports. The same spec says STDIO transports should retrieve credentials from the environment rather than follow the HTTP OAuth flow.⁴

Does OAuth solve MCP authorization?

OAuth solves only part of the problem. OAuth can establish an authorization flow, issue tokens, and let a protected MCP server validate bearer tokens. The MCP server still has to decide whether the token subject may perform the specific tool action against the target resource.

What did CVE-2026-8719 prove?

CVE-2026-8719 proved that a valid-token path can still miss local capability enforcement. NVD and Wordfence describe AI Engine 3.4.9 as accepting any valid OAuth token for MCP access without verifying administrator privilege before admin-level MCP tools became reachable.¹²

What should MCP builders test first?

Test denial paths first: low-privilege token to admin tool, read-only token to write tool, valid token to another tenant’s resource, expired token, wrong-audience token, and destructive tool without approval. Passing happy-path OAuth does not prove action-level authorization.

Why does tool cloning matter for MCP security?

Tool cloning matters because repeated implementations can repeat the same vulnerable middleware, auth shortcuts, and missing checks. The May 2026 tool-cloning paper found high verified clone rates in high-similarity MCP candidates and warned that hidden duplication can propagate vulnerable implementations.⁶

References