Please formally document Permissions-Policy: tools=() as a security control

[DMXMax]

Summary

The tools permissions policy feature is implemented in Chrome 150 and
confirmed working empirically. When Permissions-Policy: tools=() is set
as an HTTP response header, any call to navigator.modelContext.registerTool()
throws:

SecurityError: Failed to execute 'registerTool' on 'ModelContext': Access to the feature "tools" is disallowed by permissions policy.

This is a meaningful defensive control for site owners who want to prevent
WebMCP tool registration on pages where it should never be active —
authenticated account pages, payment flows, sensitive data pages.

It is enforced by Chrome above the JavaScript layer, meaning injected
JavaScript cannot bypass it regardless of load order or shadow attacks.

The problem

This control is not mentioned anywhere in the public spec, proposal, README,
or security-privacy.md. Site owners and security teams cannot rely on an
undocumented behavior that may change without notice.

Request

1. Formally document Permissions-Policy: tools=() in the security
   considerations section of the spec
2. Clarify whether this is intentional as a security control or incidental
   web platform practice
3. If intentional, provide guidance on recommended use — specifically for
   pages that should never expose WebMCP tools

Reference

Chromium source: third_party/blink/renderer/core/script_tools/model_context.cc

if (!ExecutionContext::From(script_state)->IsFeatureEnabled(
        network::mojom::PermissionsPolicyFeature::kTools)) {
    exception_state.ThrowSecurityError(kPermissionPolicyNotEnabledError);

Tested on Chrome 150.0.0.0 with #enable-webmcp-testing flag enabled.

[victorhuangwq]

The Chrome contributors will propose the spec changes soon, as per #160

[domfarolino]

Yep, this is coming this week!

[beaufortfrancois]

@DMXMax #179 has been merged. See https://webmachinelearning.github.io/webmcp/#permissions-policy

[domfarolino]

Yeah, I guess the OP is asking for explicit documentation that shows you can disable the feature even in top-level frames via Permissions-Policy: tools=(), to protect your site from script that might want to register tools suitable for agents. But I'm not sure that kind of documentation is necessary in the spec. But we can stick it in the TAG Security and Privacy questionnaire...

[ck-glen-clarkson]

(Posting from my work account — original issue #178 was filed from my personal @DMXMax account. I'm a Staff Product Security Engineer at Credit Karma/Intuit)

Thanks @victorhuangwq, @beaufortfrancois, and @domfarolino — appreciate the quick turnaround on PR #179. Documenting the permissions policy in the spec addresses the core of what I raised.

Let me clarify the ask, because I conflated two things originally. The spec now answers "what is the permissions policy?" What I'd like to make a case for is "when should a site owner deliberately set tools=() as a defensive posture?" — a different question for a different audience.

The TAG questionnaire is a good fit for the audience that uses it. My concern is the audience gap on the deployer side — site owners and security teams typically reach for the spec, MDN, and OWASP-style resources rather than W3C process documents. By analogy: CSP's spec describes the mechanism, but the defensive patterns (strict-dynamic, nonces, strong policy templates) live where deployers actually look. Either way, it is a huge help that this control exists at all.

What I'd suggest is a brief non-normative note in Security Considerations:
"Site owners can disable the feature on pages where tool registration is not an intentional capability by setting Permissions-Policy: tools=(). This is enforced by the user agent above the JavaScript layer and is not bypassable by same-origin script."

That puts the guidance where deployers look without committing the spec to prescriptive recommendations. Happy to draft as a PR if its helpful.

[victorhuangwq]

I agree that site owners will mostly look to MDN, so when it starts moving over, we should figure out a way to provide guidance there as well. @captainbrosset FYI.

On the non-normartive note itself, while the broader spec is developing, I actually think what you are proposing already sounds reasonable and worth adding.

Just curious, I'm assuming you are mostly thinking about defence-in-depth against compromised third-party scripts?

[ck-glen-clarkson]

Thanks @victorhuangwq — defense-in-depth against compromised third-party scripts is one motivation, but not the whole picture. The threat I'm aiming at is broader: any unintended JavaScript execution path on a sensitive page. That includes XSS in first-party code, compromised dependencies, and persisted service workers, alongside third-party script compromise.

I have a demo that used injection to register a ToolCreationTool. I then got the host LLM to use that tool to write and execute exfiltration code. This was JS the page owner didn't intend to execute. Permissions-Policy: tools=() cuts that whole class off above the JS layer, which is what makes it useful as a deliberate defensive posture.

That ties into @johannhof's #181 — I saw the TODO in "Violation of Same-Origin Boundaries" pointing back here. Worth flagging that the defensive value of tools=() isn't only cross-origin. It protects against same-origin unintended tool registration as well, which is where most of the practical injection threats live. I'd want any guidance we add to make both axes explicit, so site owners don't read "Permissions-Policy" and conclude it's only relevant to cross-origin scenarios.