MCP Mitigation Controls ¶

Wallarm protects MCP servers at two levels. Standard attacks (SQL injection, XSS, path traversal, etc.) are detected automatically since MCP operates over HTTP with JSON-RPC payloads. For MCP‑specific threats, Wallarm provides three dedicated mitigation controls:

• ACL policy - controls who can access specific MCP methods and primitives

• Request verification - verifies that request parameters contain expected values before allowing the request

• Tool input schema enforcement - validates tool call arguments against the schema learned from tools/list

Requirements¶

• The Advanced API Security subscription plan

• NGINX Node 6.12.0 or higher, or Native Node 0.25.0 or higher

• API Discovery active (MCP discovery is enabled by default)

• For ACL policies by user or role: configure MCP user and role extraction in MCP session context parameters. IP address and country are available automatically.

• For request verification: any parameters you want to check (e.g., JWT claims) must be exported as session context parameters so the node can evaluate them.

Creating MCP mitigation controls¶

To create an MCP mitigation control:

1. Go to Wallarm Console → Mitigation Controls → Add control.

2. Select the desired control type:

   • ACL policy
   • Request verification
   • Tool input schema enforcement

3. Configure the control as described below.

ACL policy¶

The ACL policy control restricts access to specific MCP methods and primitives based on the identity or network properties of the request source.

MCP servers often expose powerful tools - deleting accounts, transferring funds, accessing internal databases - that should only be available to authorized actors. Without access control at the MCP layer, any AI agent with network access to the server can invoke any tool. This control lets you define allow/deny rules based on user, role, IP address, or country.

For example, you can allow only users with the admin role to call the delete_account tool, or block access to all MCP tools from specific countries.

Configuration¶

Attack type¶

When verification fails, an ACL violation attack is registered.

Example¶

A CRM system exposes an MCP server at crm.example.com/mcp with tools like delete_account, update_opportunity_stage, and list_contacts_for_account. The delete_account tool should only be accessible to administrators - no other user or AI agent should be able to invoke it.

Create an ACL policy with:

• MCP server: crm.example.com/mcp

• Methods: tools/call

• Primitives: delete_account

• Access mode: Allow

• Access objects: User role = admin

With this policy, only agents acting on behalf of users with the admin role can call delete_account. All other requests to this tool are blocked with a 403 response and an ACL violation attack is registered.

Request verification¶

The request verification control checks that specific parameters in an MCP request contain expected values before allowing the request to proceed.

MCP requests often carry important context: JWT tokens with scoped permissions, client identifiers, tenant IDs. However, the MCP server itself has no built-in mechanism to validate this context -it simply processes whatever the AI agent sends. This control closes that gap by letting you define what values must be present in specific request fields (headers, JWT claims, body parameters) for each method and primitive.

For example, you can require that tools/call requests to profile_read carry a JWT with the profile:read scope, or that the X-Client-Id header matches an expected tenant identifier.

Configuration¶

Attack type¶

When verification fails, an MCP request verification failure attack is registered.

Example¶

A CRM MCP server uses OAuth with JWT tokens. The get_user_profile and get_account_details tools should only be callable by agents whose JWT token contains the profile:read scope. An AI agent acting on behalf of a user who only granted calendar:read should not be able to read profiles.

Create a request verification control with:

• MCP server: crm.example.com/mcp

• Methods: tools/call

• Primitives: get_user_profile, get_account_details

• Scope verification: point to the scope claim in the JWT payload, expected value profile:read

• Mitigation mode: Blocking

With this control, if the agent's JWT token does not contain profile:read in its scope claim, the request is blocked with a 403 response and an MCP request verification failure attack is registered.

Tool input schema enforcement¶

The tool input schema enforcement control validates that MCP tools/call arguments conform to the input schema published by the MCP server. No spec upload is required - API Discovery automatically captures tools/list responses, learns the expected schema (parameter names, types, required fields) for each tool, and distributes it to all nodes via the Wallarm Cloud.

MCP tool calls accept free-form JSON arguments, which makes them a natural target for injection attacks - an attacker or compromised agent can pass unexpected parameters, wrong types, or call tools that don't exist. This control enforces the schema learned by API Discovery on every tools/call request - blocking calls with unknown arguments, wrong types, or calls to tools not present in the schema.

Configuration¶

Attack type¶

When a violation is detected, an Invalid tool call attack is registered. This includes:

• Calls to tools not present in the tools/list response (if Allow tools undefined in the schema is disabled)

• Arguments with types that do not match the schema

• Unknown arguments not defined in the tool's input schema

Example¶

A CRM MCP server exposes tools like get_user_profile(user_id: string) and list_accounts(limit: integer). A compromised AI agent sends a tools/call request to get_user_profile with {"user_id": "123", "__proto__": {"admin": true}} - injecting an extra parameter not defined in the schema. Another agent calls a tool named exec_command that doesn't exist on the server.

Create a tool input schema enforcement control with:

• MCP server: crm.example.com/mcp

• MCP tools: All

• Allow tools undefined in the schema: Off

• Mitigation mode: Blocking

With this control, the __proto__ parameter is rejected as an unknown argument, and the exec_command call is rejected as an unknown tool. Both are blocked with a 403 response and an invalid tool call attack is registered.

Viewing detected attacks¶

Attacks detected by MCP mitigation controls are displayed in Wallarm Console → API Sessions → MCP Sessions tab. Each session shows the MCP server, requested primitives, and individual requests with their MCP method and primitive name.

In the request details, the attack type and back-link to the mitigation control that triggered detection are displayed.

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send