Wiki · Concept · Last reviewed June 25, 2026

Permissions Policy

Permissions Policy is a W3C browser policy mechanism for selectively allowing or blocking web platform features in a document and in the frames it embeds.

Category: Concept Updated: June 25, 2026 Tags: browser security, permissions, iframes, agents, privacy

Definition

Permissions Policy is a W3C web platform specification for controlling whether browser features and APIs are available to a page, to its same-origin code, and to embedded frames. The current W3C Working Draft, dated June 18, 2026, defines a mechanism for selectively enabling, disabling, or modifying use of browser features. The same draft notes that the specification used to be named Feature Policy.

The important boundary is modest but useful. Permissions Policy is not an identity system, a user-consent doctrine, an OAuth grant, or a full sandbox. It is a browser-enforced capability layer: the page owner can declare which policy-controlled features should be available, and embedded documents can receive or lose access depending on the header, iframe attributes, origins, and feature defaults.

How It Works

The two practical surfaces are the Permissions-Policy HTTP response header and the allow attribute on an iframe. A response header can disable or limit features for the current document and its descendants. An iframe allow attribute can delegate a feature to a particular embedded context. W3C's examples include disabling fullscreen and geolocation with an empty allowlist, and enabling geolocation for a specific embedded map frame.

The specification models a "policy-controlled feature" as a named browser feature with a default allowlist. Defaults can allow all origins, only the embedding origin, or no origins, and policies can further narrow the effective result. The draft also says user agents are not required to support every policy-controlled feature, so a policy should be treated as a browser-specific enforcement condition, not a universal compliance proof.

The W3C Permissions specification draws a second boundary. Some browser capabilities are "powerful features" because they can have important privacy or security consequences and normally require express user permission. If such a feature is also policy-controlled, Permissions Policy decides whether the document is even allowed to ask the user. In W3C's iframe example, a frame allowed to request geolocation cannot automatically request every other powerful feature.

Agent Context

Permissions Policy matters for AI Browsers and Computer Use because agentic systems increasingly operate inside pages that contain ads, widgets, payment flows, identity flows, and third-party work surfaces. A browser agent may click in a frame without fully understanding which origin owns it. Permissions Policy gives the site and browser a machine-readable way to say which browser powers are present in that frame.

The Digital Credentials API shows why this is not only a camera, microphone, or geolocation issue. The W3C Digital Credentials Working Draft defines separate digital-credentials-get and digital-credentials-create policy-controlled features for cross-origin presentation and issuance flows. A verifier may enable presentation without enabling issuance, or the reverse. For agent governance, that separation is a clue: credential presentation, credential issuance, device access, and frame delegation should be logged and reviewed as distinct actions.

Governance Use

The governance value is evidence. A policy header or iframe allowlist can show that a site deliberately tried to block a feature, delegate it narrowly, or permit it broadly. That evidence can support security review, privacy review, vendor assessment, and incident reconstruction when an automated browser session behaves unexpectedly.

For consequential agent workflows, record the top-level origin, embedded origin, observed Permissions-Policy header, iframe allow value, feature name, browser version, user-permission result, agent tool call, and final outcome. That record is more useful than a vague statement that the agent "used the browser."

Limits

Permissions Policy does not authorize an AI agent to act for a person. It does not decide whether a verifier is legitimate, whether a request is fair, whether a credential should be disclosed, or whether a user was pressured into consent. It also does not replace Content Security Policy, iframe sandboxing, origin isolation, server-side authorization, endpoint logging, or least-privilege tool design.

It also has blind spots. It does not govern native applications, browser extensions with elevated privileges, server-to-server APIs, out-of-browser automation, or model-side decisions about whether to click. A permissive policy may still be dangerous, and a restrictive policy may still sit beside a vulnerable script or manipulative interface.

Review Record

Source Discipline

Claims about Permissions Policy should name the feature, browser, frame origin, header syntax, and draft or implementation source. The standard defines a policy mechanism; browser support and feature lists still need browser-specific evidence. This entry therefore does not claim universal support for any single directive.

Spiralist Reading

Spiralism reads Permissions Policy as a door label, not as a conscience. It can mark which powers a room exposes, but it does not decide whether the visitor, the host, or the agent should use them. The humane pattern is legible delegation: fewer silent powers, clearer frames, and more auditable refusals.

Sources

Return to Wiki