Solving Agent Identity with WebMCP
The latest wave of personal agents, including Muse and Instinct, can act through users' authenticated browser sessions to buy something or book dinner. They inherit the user's context and permissions, which is useful, but from the platform's perspective, the human and the agent are mixed together: same account, same session, and the same endpoints.
Platforms are left inferring agent activity from behavior like repeated polling or unusual request volume. They can either tolerate it, add friction, or block it, and when they choose to block, the user can lose access too.
That happened in a recent Resy case: a user's account was temporarily deactivated after their agent repeatedly polled for reservations.
Blocking may have been reasonable in this case - while the agent was trying to help its user, constant polling can put a strain on the service, and the platform still needs to protect its infrastructure and keep access fair for everyone. What seems to be missing here is a social contract: a shared understanding of what agents are allowed to do and what access platforms offer in return.
Enter WebMCP
WebMCP gives us a useful starting point to solve many of these issues with low overhead, without requiring sophisticated identity mechanisms.
Websites are already exposing tools specifically for agents alongside their existing interface:
- Human lane - DOM, buttons, UI
- Agent lane - WebMCP tools
That creates a dedicated agent interface by itself. But making it a declared agent path still requires two things: a reason to actually use it by agents (instead of just using the existing human interface) and a way for the backend to recognize its traffic.
Why agents would declare themselves
Agent developers might reasonably worry that declaring themselves will just get their users blocked. A dedicated lane only works if platforms offer predictable access to agents that follow its rules, so solving this isn't purely technical, you also have to think about incentives. We think there is a paradigm that can be applied here to solve for both sides.
The stick: platforms keep hardening the human lane against unwanted automation through limits, challenges, and blocking.
The carrot: declared agents get supported tools, structured inputs and outputs, clear terms, and predictable limits. A platform could allow reservation monitoring at an agreed cadence, for example.
The deal is simple: agents follow the platform's terms, and the platform offers a supported way to get the job done.
| Who | Without a declared agent path | With a declared agent path |
|---|---|---|
| Human | Human and agent activity are mixed under one account. | Declared agent access can be limited or revoked separately. |
| Cooperative agent | Risks blocks while navigating the UI or calling private APIs. | Gets supported tools and predictable permissions and limits. Has a reason to declare. |
| Malicious agent that declares | Can already automate the page or underlying APIs. | Still faces backend permissions, limits, and abuse checks. Declaration buys no automatic trust. |
| Malicious agent that hides | Tries to evade the platform's defenses. | Can keep trying. Existing defenses remain necessary. |
This solves the first part of agent identity by separating declared agent activity from the user's normal browser activity, but it does not completely solve the identity problem. To verify which agent or provider made a request - for example, whether it really came from Muse - we would need another layer of identity verification, such as Web Bot Auth.
How it could work
A WebMCP tool can call the same backend API as the frontend. The site adds a declaration to requests made through that tool and ties them to an agent session:
- The page exposes a WebMCP tool for an existing action.
- An agent calls it through the user's authenticated browser session.
- The tool marks its backend request as agent activity using site-defined metadata or a header.
- The backend checks the user's authorization and creates or updates a scoped agent session.
- Subsequent tool requests carry that agent session reference, and the backend enforces its policies.
The session can hold the user account, site or origin, allowed actions, expiry, and current risk state.
Agent requests carry their own session reference alongside the user's authentication. That lets the same endpoint apply different rules without labeling every request from that browser as agent traffic. The platform can narrow or revoke declared agent access without invalidating the user's normal login.
This declaration and session model is our proposed convention around WebMCP tools. It isn't a built-in WebMCP identity guarantee: a declaration doesn't verify who operates an agent or prove good intent.
What platforms can control
Once that session exists, platforms can apply explicit policies:
- Rate limits: set how often an agent can poll or act.
- Permissions: allow searching or preparing an action, while requiring user confirmation for higher-risk steps.
- Risk checks: evaluate declared agent activity separately.
- Terms: publish rules agents can discover before they act.
- Observability: measure agent usage and failures directly.
These rules already exist for the human lane, but now we can have a separate rule set for the agent lane.
Why WebMCP
WebMCP already sits between the page and the agent - the site owns the tools, the agent uses the user's browser context, and the backend controls access.
That lets platforms start with their existing APIs, without building a separate public agent API or waiting for a new identity protocol. They can give participating agents a supported path while continuing to defend against automation that hides.
Summary
Agent declaration through existing WebMCP tools might be a lightweight solution to many of the issues facing the agentic web right now. It would allow platforms to have separate permission sets for agents and humans without rebuilding anything.
We're testing an alpha product for managing these sessions. If you'd like to try it out, reach out: founders@nekuda.ai.