Containing the Playwright Model Context Protocol server with domain allowlists and blocked actions

Why native options are one layer, not the boundary

The Playwright MCP server gives an AI agent a real browser. The agent can navigate to arbitrary sites, submit forms, execute scripts, upload and download files, and read page content. A prompt injection embedded in a page, or an agent that simply misreads its task, can turn those abilities toward unapproved domains or unauthorized actions.

The server's own options, such as allowed and blocked origins and capability restrictions, reduce that exposure. They are not a security boundary on their own. They run inside the same process and trust domain as the thing being contained, and they cannot see DNS, direct-IP connections or what the rest of the host does.

OWASP's MCP guidance points the same way. It says never to fetch arbitrary URLs supplied by the LLM without strict allowlist validation, and it recommends treating each MCP server as an untrusted, independent security domain. MCP servers also operate with delegated user permissions and chained tool calls, so one injected instruction can propagate across several calls before anyone notices.

Configuring the server: allowlist and blocked actions

Start with the narrowest origin list the workflow can tolerate. Use exact hostnames rather than broad patterns, and keep the list in version control so changes are reviewed. Add blocked origins for destinations that must never be reached, such as internal administration consoles, metadata endpoints and file-sharing or paste sites. Then remove capabilities the task does not require. An agent that only reads public documentation does not need file upload or script execution enabled at all.

Configure the browser environment as part of the same exercise. Use a separate, disposable browser profile with no saved sessions, cookies or stored credentials. Issue credentials per run and keep the agent away from local credential stores, so a hijacked session exposes less.

Do not assume a page on an allowed origin stays on that origin. Pages redirect, and they load subresources from other hosts. Test how your deployed server version treats redirects and subresource requests, and write down the result. Where the server does not constrain them, the network layer has to. Permissions also tend to expand over time, so review the allowed set on a schedule and treat additions as controlled changes.

Per-tool-call policy: allow, redact, block, escalate

Origin settings answer where the browser may go. They do not answer what the agent may do once there. That needs policy applied to individual tool calls in the execution path, evaluated before the call runs and recorded with its outcome.

A workable default sorts calls by consequence. Reading page content on allow-listed origins can usually be allowed, with redaction where pages return sensitive values. Navigation should be checked against the exact-target allowlist on every call, including URLs the model composed itself. Script evaluation, file upload, form submission and file download carry the most risk, because they change state, move data or bring untrusted content onto the host. Block them by default, and escalate to a human approver only for workflows with a documented need.

Tool arguments are an attack surface too. OWASP documents credential exfiltration through tool arguments, poisoned tool descriptions, shadowed tool names and definitions that change after approval. Keep an allowlist of approved servers and tools, require re-approval when definitions change, and do not let agents discover and connect to servers without approval.

Enforcing policy on MCP tool calls with Trussed

The server settings and network controls above can be built from standard components. What is harder to build is consistent per-call policy in the execution path, with evidence generated by the enforcement itself rather than reconstructed later.

Trussed is one way to do this. It enforces policy in the execution path across models, agents, tools and MCP servers, scoped to individual interactions and tool calls. Each call can be allowed, redacted, blocked, rate limited or escalated for human approval, enforced at runtime, not reviewed after the fact. The enforcement produces continuous, audit-ready evidence of what was permitted and what happened, and it can be deployed self-managed in the customer's cloud with configurable retention and data residency.

Trussed complements the layers described here and does not replace sandboxing or network egress controls. It has run continuously in production at a regulated enterprise for more than 18 months, and it supports teams that need to show a regulator or auditor what their AI was allowed to do and what it did.