# Client-Supplied Hints Are Not Security Boundaries A security boundary must be enforced by the party that owns the resource, from that party's own configuration — never inferred from information the counterparty supplies about itself. The instant an access decision is gated on a value the other side sends ("here are the paths I'm allowed to touch," "here's my role," "this request is internal"), the boundary is only as trustworthy as the least-trustworthy caller, because the caller controls the input the check reads. A hint from the counterparty can inform behavior, but it cannot *be* the enforcement; the owner has to decide from state the counterparty can't set. <!-- atomicity: 1 idea ✓ --> ## Why This Matters This is the explicit rationale for MCP 7-28 deprecating Roots. Roots let a client tell a server which filesystem paths it was allowed to access, and servers were tempted to treat "this path is inside the client-sent Roots, therefore it's safe" as an access decision. The spec reclassifies Roots as *informational guidance*, not access control, precisely because the protocol never confined the server to those paths — the security decision has to move to means the server itself owns: launch arguments, resource URIs, server configuration, environment variables. The client's Roots become a hint the server may use for UX, not the fence. The principle generalizes to every trust-boundary bug of this shape. `X-Forwarded-For` as an auth signal, a `role` field in a request body, a `isAdmin` cookie the client can edit, CORS "origin" treated as identity, a JWT trusted without signature verification — all are the same mistake: reading the counterparty's self-description as if the owner had asserted it. The fix is always the same move — relocate the decision to authority the owner controls (server-side session, verified signature, resource-owner ACL), and demote the counterparty's input to at most a hint that still gets checked. The one exception proves the rule: a hint *cryptographically bound to an authority* (a properly verified signed token) is no longer a mere hint, because the owner can verify the authority behind it rather than trusting the claim. ## Scope & Conditions - **Holds** for every boundary where one side owns a resource and the other requests access to it — protocols, APIs, RPC, web requests, agent/tool interfaces. - **The distinction from data sanitization:** [[3. Resources/Permanent Notes/Sanitize by Value Not by Input Type]] is about not trusting the *value/type* of input reaching a sink; this note is about not trusting the *authority/provenance* the counterparty claims. One guards against malformed data, the other against forged authority — different failures, same root instinct of misplaced trust in the other side's self-report. - **Breaks (i.e., the hint becomes usable) only** when the hint is bound to verifiable authority the owner can independently check (signatures, attestation), at which point it's no longer counterparty self-assertion. ## Links - [[3. Resources/Literature Notes/Introducing MCP 7-28 for AI Application Developers — What Goes Away, and What Might Break]] — the origin: Roots deprecated because "inside the client-sent Roots therefore safe" blurred the security boundary; access scope moved to server-owned config - [[3. Resources/Permanent Notes/Sanitize by Value Not by Input Type]] — the sibling trust failure: that one is untrusted *data*, this one is untrusted *authority claims*; both are "don't trust the other side's self-report" - [[3. Resources/Permanent Notes/Bounded Action Spaces Not Better Models Make Agents Safe to Run]] — the agent-safety application: bound what an agent may attempt from the owner's configuration, not from the agent's own claims about what it intends - [[3. Resources/Permanent Notes/Client-Side Processing Does Not Move the Server Trust Boundary]] — applies-in: browser-generated media and metadata remain client claims that the server must validate. ## Source - [[3. Resources/Literature Notes/Introducing MCP 7-28 for AI Application Developers — What Goes Away, and What Might Break]] — Junghwan Park / AAIF (2026): SEP-2577's reclassification of MCP Roots as informational guidance, not access control; access scope belongs in tool parameters, resource URIs, server config, or environment variables. Reader doc 01kxpp2e7k16rtsdgwmwschwzz. - See also: [[3. Resources/MOCs/AI Agent Safety MOC]]