# Overview (/en/docs/platform/features/builders/permissions-policy) The Permissions-Policy builder writes a [Permissions-Policy](/en/docs/web-security/policies/permissions-policy) header from your own reports. This header tells the browser which features, such as the camera, geolocation, or the payment sheet, your pages and the frames they embed may use. You pick the reports to learn from, start from a preset or your own policy, grant each feature to the pages and frames that use it, and copy the headers. The builder lives under each website, in the sidebar, as **Builders** > **Permissions-Policy**, next to the [CSP builder](/en/docs/platform/features/builders/csp) and the [Connection-Allowlist builder](/en/docs/platform/features/builders/connection-allowlist). It works on every plan, and every website role can use it. For what the three builders share, refer to [Builders](/en/docs/platform/features/builders). The builder grants each feature to the pages and frames that browsers reported using it. Anyone who knows your reporting endpoint can send reports to it, so a granted feature is not proof that your pages use it. Review the grants before you deploy, starting with the features granted to another origin. A policy from the API or the MCP tool applies the same defaults with no review, so check it the same way. Always deploy a new policy with the `Permissions-Policy-Report-Only` header first. Switch to `Permissions-Policy` only once a week or more of reports shows that nothing your pages need would be blocked. ## What the Permissions-Policy builder produces [#what-the-permissions-policy-builder-produces] The builder ends with two response headers, ready to paste into your server or content delivery network (CDN) configuration. A [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) header points reports at your website's CentralCSP endpoint. A `Permissions-Policy-Report-Only` header carries the policy, or `Permissions-Policy` once you switch to enforce mode. Each feature in the policy reads one of three ways. `()` denies it everywhere, `self` grants it to your own pages, and a quoted origin grants it to a frame from that origin: ```http Permissions-Policy-Report-Only: camera=(), geolocation=(self), payment=(self "https://pay.example.com") ``` The builder writes no `report-to` parameter in the policy. Its reports go to the endpoint named `default`, which the `Reporting-Endpoints` header declares next to `centralcsp`. Refer to [The default endpoint](/en/docs/web-security/reporting-api/concepts/default-endpoint). The builder does not save or deploy anything, and unlike the CSP builder it does not grade the policy. It gives you the headers, and you add them to your site. Each export, the headers as TXT or the review table as CSV, is recorded in the [audit log](/en/docs/platform/security/audit-log#exports). ## How it works [#how-it-works] The builder works in four steps. Each step reuses the answer of the one before it. 1. **Period**: Choose which days of reports to learn from, up to the last 30. 2. **Starting policy**: Start from a preset, by default one that denies every listed feature, or paste the policy you send today. 3. **Review features**: Grant or reject each feature, for your own pages and for each frame origin. Every row starts decided for you: what your pages and frames used is granted, and noise and features only a third-party script reached for start rejected. 4. **Deploy**: Pick report-only or enforce mode, and copy the headers. The defaults keep working what your pages and frames used in the period, and deny the rest of the catalog. The Permissions-Policy builder on the Period step, with 7 days selected, the report chart, and the Reports, Features used, and Look like noise counters ## Where the data comes from [#where-the-data-comes-from] The builder reads two report types your website already collects: * A [Permissions-Policy violation](/en/docs/web-security/reporting-api/reports/permissions-policy-violation) report, sent when one of your pages uses a feature the policy blocks. It becomes a grant to `self`. * A `potential-permissions-policy-violation` report, sent when an iframe's `allow` attribute asks for a feature. It becomes a grant to that frame's origin. The [Permissions Policy reports](/en/docs/platform/monitoring/permissions-policy) page shows the same data, as its **Violations** and **Potential** views. For why the **Potential** view matters before you enforce, refer to [Check Potential before you enforce](/en/docs/platform/monitoring/permissions-policy#check-potential-before-you-enforce). ### Why there is no detected policy [#why-there-is-no-detected-policy] A CSP report carries the policy that produced it, so the CSP builder can detect the policy you serve. A Permissions-Policy report never carries the served policy. The builder cannot see what you send today, so it starts from a preset, or from the policy you paste. The review then adds what your site was reported using. For how the builder turns reports into grants, flags noise, and writes the header, refer to [Builder decision rules](/en/docs/platform/features/builders/permissions-policy/how-it-decides). ## Use it from the API and the MCP server [#use-it-from-the-api-and-the-mcp-server] The REST API builds the same policy without the wizard. The **Build a recommended Permissions-Policy** endpoint takes an optional period and an optional starting policy, and returns two header values: `policy` for the Permissions-Policy header and `reportingEndpoints` for the `Reporting-Endpoints` header. Without a starting policy, it denies every listed feature, then grants back what your pages and frames used, with noise and third-party-only features left out. Refer to the [API reference](/en/docs/api-mcp/api). The [Model Context Protocol (MCP) server](/en/docs/api-mcp/mcp) exposes that endpoint as the `build_recommended_permissions_policy` tool. ## Next steps [#next-steps] * [Get started](/en/docs/platform/features/builders/permissions-policy/get-started) * [Review table](/en/docs/platform/features/builders/permissions-policy/review-features) * [Builder decision rules](/en/docs/platform/features/builders/permissions-policy/how-it-decides) * [Permissions Policy reports](/en/docs/platform/monitoring/permissions-policy) * [Permissions-Policy reference](/en/docs/web-security/policies/permissions-policy) * [Lock down browser features with Permissions-Policy](/en/blog/permissions-policy-explained)