WebMCP Security Guide: Preventing Privilege Abuse in Browser Agents

The Web Model Context Protocol (WebMCP) is a browser standard co-proposed by Google and Microsoft, with an origin trial starting in Chrome 149. Unlike traditional methods where agents scrape screen captures or DOM trees, WebMCP allows web apps to directly expose structured tools to agents, enabling faster and more reliable interactions.

However, WebMCP tools run while sharing the user’s current browser session and login cookies. If an agent reads malicious external emails or reviews and is exposed to indirect prompt injection, it can lead to the 'confused deputy' problem, where the agent misuses user privileges to delete accounts or execute unauthorized payments.

Primary Defense via HTTP Response Headers: Origin Isolation and Permission Policies

The core defense in WebMCP to ensure web agents operate safely within the browser starts with establishing strict origin isolation and permission policies via HTTP response headers. If a server fails to provide proper security headers when a browser renders a page, it may be exposed to malicious scripts or attacks from adjacent domains. This blocking stage is essential, especially given that agents operate by sharing the user's login session and privileges.

Specifically, you should request dedicated process isolation for the same origin by specifying the Origin-Agent-Cluster: ?1 header. According to Chromium issue #521181015, in environments without explicit isolation, relaxing document.domain between subdomains can lead to security vulnerabilities where another origin might hijack a victim origin's WebMCP tool context to register and execute arbitrary tools. To fully prevent this, you must configure the system to assign independent origin agent clusters at the page level.

In addition, you should apply the WebMCP-specific permission policy Permissions-Policy: tools=(self). This policy prevents untrusted external resources, such as sub-iframes, from registering tools at will. For sensitive paths where agents should never intervene—such as payments or authentication—a strategy of specifying tools=() to block WebMCP functionality entirely is highly effective.

To conveniently and securely manage these security headers in a Fastify backend, you can utilize hooks to dynamically inject headers during the response transmission phase as shown below.

typescript

import Fastify from 'fastify';

const fastify = Fastify();

// WebMCP 보안 규격을 준수하기 위한 헤더 주입 훅
fastify.addHook('onSend', async (request, reply, payload) => {
  // 전용 프로세스 격리를 요청하여 인접 도메인 간의 간섭 방지
  reply.header('Origin-Agent-Cluster', '?1');

  // 민감한 경로에서는 WebMCP 기능을 완전히 비활성화하고, 그 외에는 동일 오리진만 허용
  if (request.url.startsWith('/checkout') || request.url.startsWith('/auth')) {
    reply.header('Permissions-Policy', 'tools=()');
  } else {
    reply.header('Permissions-Policy', 'tools=(self)');
  }

  return payload;
});

Client-Side Safety Hints and Metadata Annotations

To prevent browser agents from performing unintended actions due to corrupted malicious data, you must provide clear safety hints starting from the client-side tool registration phase. By using the document scope API document.modelContext.registerTool introduced in Chrome 150, you can convey detailed privilege control guidance to the agent via metadata annotations. Specifically, for tools handling unverified external inputs like user reviews or external web search results, you must declare untrustedContentHint: true to ensure the agent treats this data as raw text rather than executable instructions.

For tools used for simple retrieval, declaring readOnlyHint: true can prevent degraded user experience caused by excessive authorization prompts. Conversely, for irreversible writing tools such as data deletion or payments, injecting consequentialHint: true ensures that the browser-level design strictly requires explicit user confirmation. Additionally, to prevent security incidents, you must strictly limit tool descriptions to 500 characters and parameter descriptions to 150 characters to fundamentally block prompt injection attempts that use the description field as an attack vector.

Here is an example implementation of a client-side JavaScript for securely registering tools.

javascript

const controller = new AbortController();

await document.modelContext.registerTool({
  name: 'get_user_comment',
  description: '사용자 댓글 목록을 안전하게 읽어옵니다.',
  untrustedContentHint: true, // 외부 작성 콘텐츠를 포함함을 명시
  readOnlyHint: true,          // 부수 효과가 없는 안전한 조회 작업
  parameters: {
    type: 'object',
    properties: {
      commentId: { type: 'string' }
    },
    required: ['commentId']
  }
}, async ({ commentId }) => {
  const res = await fetch(`/api/comments/${commentId}`);
  return res.json();
}, { signal: controller.signal });

By combining AbortController signals, which allow flexible control over the tool's lifecycle, with core safety hints, you can build a preemptive defense layer in the browser and agent stack, even in the event of abnormal calls.

Zero-Trust Server-Side Validation and Fastify Schema Design

The WebMCP JSON schema declared on the client-side cannot serve as a complete security perimeter. In real browser agent environments, it is common for arbitrary extra properties or data types that do not match the declared specification to be sent to the backend without validation. Therefore, zero-trust re-validation based on strict schema enforcement at the Fastify backend server level is essential.

The most reliable way to solve this is by using TypeBox, the official Fastify type provider, to synchronize runtime validation and type compilation. In particular, enabling the Ajv option removeAdditional: 'all' in the Fastify environment allows you to completely block contaminated properties not defined in the schema, preventing unwanted data from entering your business logic.

typescript

import Fastify from 'fastify';
import { TypeBoxTypeProvider } from '@fastify/type-provider-typebox';
import { Type } from '@sinclair/typebox';

const server = Fastify({
  ajv: {
    customOptions: {
      removeAdditional: 'all' // 허용되지 않은 추가 프로퍼티 자동 제거
    }
  }
}).withTypeProvider<TypeBoxTypeProvider>();

server.post('/api/webmcp/execute', {
  schema: {
    body: Type.Object({
      toolName: Type.String(),
      arguments: Type.Object({
        accountId: Type.String({ format: 'uuid' }),
        amount: Type.Number({ minimum: 0.01 })
      }, { additionalProperties: false })
    })
  }
}, async (request, reply) => {
  const { toolName, arguments: args } = request.body;
  // 검증 완료된 args 객체 안전하게 사용
  return { success: true, toolName, data: args };
});

Applying this structure ensures that even if a client agent injects unexpected arguments, the requests will fail at the server entry point. This establishes a final line of defense where the server protects itself even if internal browser tool calls are tampered with.

Start Securely with Progressive Enhancement

WebMCP is an experimental specification in its early stages, with an origin trial running until Chrome 156. Therefore, when adopting it in production, you should approach it with a progressive enhancement mindset, ensuring that core service features remain fully functional even without this capability. Minimizing tool exposure, isolating all write operations behind backend verification, and establishing human-in-the-loop procedures for sensitive tasks are the keys to building a secure agent environment.

Reference Links