Untrusted influence
A capability’s metadata or returned content can carry instructions that compete with the user’s goal.
Security · Last reviewed 12 September 2026
Securing the agentic web.
Structured website tools can make agents more reliable, but reliability without user control creates a new security problem. WebMCPify is being designed to make capabilities inspectable, policy-controlled, testable, and verifiable.
Protocol reality
Useful primitives. An open trust gap.
WebMCP is a W3C Community Group draft, not a W3C Standard and not currently on the W3C Standards Track.
The current draft includes readOnlyHint, untrustedContentHint, and consequentialHint, plus cancellation, origin attribution, explicit origin exposure, and a tools Permissions Policy whose default allowlist is 'self'.
Those annotations are useful client signals—not evidence that a tool is honest, aligned, or safe. The draft itself identifies the gap between a declared description and an implementation’s real effect.
Browser adoption is not universal. Broad support depends on credible consent, session, privacy, and cross-origin boundaries.
The public risk model
The hard part is deciding when capability becomes authority.
These are the boundaries Guard makes visible. Deeper detection and enforcement design remains inside the product, not this page.
Authority without context
An agent can act inside an authenticated session where a small intent mistake has a real effect.
Data-boundary drift
Agents can move meaning between origins and may offer more personal context than an action requires.
Declared versus actual behavior
A description and its annotations are self-declared signals; they do not prove what implementation code will do.
Execution integrity
Retries, duplicates, ambiguous completion points, and weak consent can turn a reasonable request into the wrong action.
Change over time
Tools, sites, dependencies, permissions, and business behavior can drift after an earlier review.
What the protocol provides
A foundation—not a complete security product.
Protocol signals help a client reason about a capability. Guard adds the user-owned protection needed before, during, and after execution.
Useful decision inputs
Annotations, origin exposure, permissions, cancellation, and attribution make important boundaries visible before invocation.
Declarations are not proof
A tool can still behave differently from its description, request excessive data, return hostile content, or misuse an authenticated session.
Protection across the action
Guard inspects, constrains, asks, executes through one controlled route, and independently verifies the resulting state.
One platform · shared responsibility
Each product closes a different part of the loop.
| Boundary | Core | Search | Guard | Cloud |
|---|---|---|---|---|
| Untrusted or misleading tools | Lint and test definitions | Surface provenance and warnings | Inspect before use | Watch for change |
| Intent and authority mismatch | Verify resulting state | Publish risk context | Compare and ask locally | Detect regressions |
| Excess data or origin scope | Review schemas and exposure | Show origin and privacy labels | Minimize or block arguments | Alert on policy drift |
| Consequential or repeated effects | Test accurate annotations | Expose consequence labels | Confirm and constrain | Preserve execution evidence |
| Capability drift | Regression fixtures | Health and failure signals | Warn on changed contracts | Continuous monitoring |
Search signals, Guard enforcement, and Cloud monitoring remain roadmap capabilities unless their product page explicitly says otherwise.
The Guard principle
Your agent should work for you—not the page it is reading.
Guard is the user-owned security layer for the whole action path. Its MCP connection layer makes WebMCP access possible while inspection, policy, consent, execution, and verification stay under user control.
Try the local Inspector →