runAccessibilityAudit · BrowserTools MCP: Risk & Policy

WHAT IT DOES

What runAccessibilityAudit does on BrowserTools MCP

AI agents invoke runAccessibilityAudit to trigger actions in BrowserTools MCP. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.

WHY IT NEEDS A POLICY

Why runAccessibilityAudit needs a policy

This tool executes an audit process on the current webpage. While audits are non-destructive and read-only in practical effect, the action of 'running' an audit constitutes triggering an operation (Execute category) rather than a simple data retrieval. The severity is low because accessibility audits have no side effects, modify no data, and pose minimal risk even if misused by an AI agent.

From the tool's definition Tool name contains 'run' and description states 'Run an accessibility audit on the current page', indicating it triggers an external operation (audit execution) whose effects depend on the page context.

Attacks that exploit this kind of access

Recommended rule Ready

Verdict

runAccessibilityAudit Rate-limited

runAccessibilityAudit stays usable, but rate-capped — a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.

View as policy code

policy.json

{
  "version": "1",
  "default": "deny",
  "tools": {
    "runAccessibilityAudit": {
      "limits": [
        {
          "counter": "runaccessibilityaudit_rate",
          "window": "minute",
          "max": 10,
          "scope": "grant"
        }
      ]
    }
  }
}

RATE-LIMIT THIS TOOL →

Instant setup, no code required.

PolicyLayer is an MCP gateway: every tool call is checked against your rule before it reaches BrowserTools MCP, so you can run agents against it safely.

FAQ

Questions about runAccessibilityAudit

What does the runAccessibilityAudit tool do? +

Run an accessibility audit on the current page. It is categorised as a Execute tool in the BrowserTools MCP MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.

How do I enforce a policy on runAccessibilityAudit? +

Register the BrowserTools MCP server in PolicyLayer and add a rule for runAccessibilityAudit: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches BrowserTools MCP. Nothing to install.

What risk level is runAccessibilityAudit? +

runAccessibilityAudit is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.

Can I rate-limit runAccessibilityAudit? +

Yes. Add a rate_limit block to the runAccessibilityAudit rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block runAccessibilityAudit completely? +

Set action: deny in the PolicyLayer policy for runAccessibilityAudit. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides runAccessibilityAudit? +

runAccessibilityAudit is provided by the BrowserTools MCP server (sugatraj/cursor-browser-tools-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.