Repository navigation
Agent-Scoped Cookies #257
Description
Today, a website can recognize a returning browser or user, but it cannot recognize a returning agent. If an agent comes back two or three months later, the site has no standard way to know it is the same agent and recover its preferences, memory, or agent-specific permissions.
A normal cookie is not enough because it is scoped to the browser profile and origin. If several agents use the same browser, they share the same cookie. What we need is the same idea, but scoped to the agent.
Historical context
-
#44 - Managing action-specific permissions identifies agent identity as necessary for persisting decisions such as “always allow this agent.” The discussion notes that cookies can store the state, but the site still needs a unique identifier to separate the state of different agents.
-
#54 - Challenging assumptions of identity within WebMCP asks whether agents should have their own identity instead of only inheriting the user’s identity. The discussion distinguishes between a verified agent identity and an opaque identifier that allows a site to recognize the same agent. The group deferred the broader identity question for the initial browser-agent scope.
-
#87 - Session and authentication context for tools focuses on carrying the user’s authentication and session state across tool calls. This solves “which user is logged in,” but not “which agent is acting for that user.”
-
#96 - Agent-to-tool trust connects these discussions and proposes that
ModelContextClientexpose browser-attested agent identity, permissions, and invocation context.
Agent-Scoped Cookies are a narrower proposal. They do not attempt to verify that an agent is genuinely Claude, Gemini, or ChatGPT. They only allow a site to recognize the same agent profile when it returns.
Proposed flow
- The site asks for permission to recognize the agent on future visits.
- The site creates an opaque Agent-Scoped Cookie.
- The agent client stores it for that specific origin and agent profile.
- The client provides it with every WebMCP interaction on that origin.
- The site uses it to recover that agent’s preferences, permissions, or history.
- The user can inspect, revoke, or reset it at any time.
Difference in scope
- Browser cookie: origin + browser profile
- Agent-Scoped Cookie: origin + agent profile
- User account: origin + user
- Session ID: one conversation or task
The identifier should never be shared across origins. Amazon and Booking should receive different identifiers for the same agent.
This provides continuity, not verified identity. For sensitive permissions or transactions, the Agent-Scoped Cookie could later be bound to a cryptographic key.
Activity
domfarolino commentedon Sep 25, 2026
Thanks for starting this discussion, and sorry for letting it hang for a while. One broader point I'll make is that I think no useful agent will limit its interaction with a site to WebMCP only. On that assumption, and related to:
...it seems that this kind of "cookie" would be best if it were somehow also exposed to the site on non-WebMCP interactions as well. In fact, this is a general trend I see with any discussion related to agent identity or separating out the identity and permission model of agents vs. users. Such proposals cater to the broader use case of "agents on the web" as opposed to just WebMCP interactions. What do you think of that?
If that's true, then I think proposals of this sort are beyond the scope of the simple WebMCP API, but since there are not many places where that discussion is happening, we can continue to have them in this repository (and just mark them as such).
MCP doesn't really have this problem because users don't use MCP. Only agents use it, so separating out the quota, rate limiting, authentication, and permission model is natural even though MCP will just call down into existing server functionality that the same user-facing REST server calls into.
"Agents on the web" seems different. WebMCP is basically an agent-only pathway, but it's not the only pathway agents interact with web content, and most useful interactions involve a mix of WebMCP tools and traditional page actuation. Since agents use a mix of both, any proposal that tries to give agents their own identity and permission model on the web should probably cover both, not just one (i.e., not just WebMCP).
This involves figuring out a way to signal to the page the distinction between when a user is clicking a button vs. when an agent is clicking a button (beacuse a WebMCP tool wasn't available). A couple ideas on how to do this:
const importantButton = document.querySelector('button#foo.bar'); importantButton.click().agentinteractionstartedandagentinteractionended, and providing a special agent-only cookie on all network requests that only gets included for interactions that happen in that window.Just some thoughts here! I'll CC @markafoltz from Chrome, @justinrushing + @nmccormack-oai from OpenAI, and @bwalderman from MSFT, since these folks actually build "native" agents that interact with web content via a mix of WebMCP tools and traditional actuation. Would love any early thoughts you have on this!
Idan-Levin commentedon Sep 25, 2026
Hey @domfarolino, thanks for the response. I generally agree and find it a very unique (and cool) situation that the browser is a shared instrument between users and agents.
What I’m suggested here is deliberately narrower - covering agent interactions through WebMCP tools. We actually wrote about a variation of this today here
I agree that ideally this should cover both WebMCP and traditional page actuation. That would cover the full spectrum, from co-browsing to agents starting headless and later interacting through the browser.
That said, I think there is some value in solving the narrower WebMCP case. Even if an agent moves between WebMCP and traditional actuation, APIs exposed through WebMCP can have agent-specific permissions, rate limits, quotas, etc. You will have holes in understanding the full session, but you can at least address one of the immediate pain points: agents using the same APIs as humans without the platform being able to apply different policies.
Regarding your suggestions - made me think there is also a second problem here that is somewhat independent of the technical implementation, which is the incentive structure. An agent can always fall back to the human interaction surface. Even if we introduce a dedicated actuation API or an agent interaction mode, an agent developer could potentially choose not to use it and instead operate through existing automation, CDP, or computer use.
So with either approach, I think we need to consider the carrot and the stick. Why should an agent developer choose the agent lane instead of the human lane? Why should it declare its activity? (i.e. the underlying assumption here is that agents can always imitate humans quite successfully).
Today the incentive may actually be the opposite - declaring yourself as an agent could mean getting blocked or rate limited, so agents have a reason not to declare.
I think the equilibrium probably requires both sides, you should make undeclared automation through the human lane harder, while giving declared agents an explicit contract with better access - known rate limits, permissions, supported actions, etc.