Managing action specific permissions

[khushalsagar]

Forking from #35 (comment) for tracking how we should think about the permission model. Here's my thinking so far:

• The browser manages a global: "can you be agentic on this site" permission. The site doesn't need to be involved for this permission.

• Action specific permissions. Say an action is destructive (deletes some files). The site would likely want user consent before that action is taken. Elicitation #21 provides a hook for that. But if the user says, "i trust this agent to take this action in the future, don't ask me again", that state has to be persisted. The site could do it but then it needs to know the Agent's identity (if multiple Agents can access the actions). The elicitation issue introduced an agent API which is meant to represent the calling agent. We could add an API to allow persisting state for it..?

[khushalsagar]

A higher level API could also be considered here, so the site doesn't have to worry about asking for and storing permission state. I was considering if the annotations concept in MCP tools is the right layer for this, something like needsUserConsent. It's a deterministic hint to the browser that this action is sensitive and the user should explicitly approve it before execution. The browser can present an option like "Always allow" to avoid repeating the permission flow.

But the annoying thing about the above is when does the browser clear the state associated with a tool? Tools right now are ephemeral, the site can change the set at anytime based on changes in application state. Like a checkout tool shows up when the user has items in their cart but not otherwise. While the "Always allow" permission state should be preserved. That's easier if the site is managing it.

[domfarolino]

But the annoying thing about the above is when does the browser clear the state associated with a tool? Tools right now are ephemeral, the site can change the set at anytime based on changes in application state. Like a checkout tool shows up when the user has items in their cart but not otherwise. While the "Always allow" permission state should be preserved. That's easier if the site is managing it.

I just want to make sure I understand the problem: it sounds like the issue is being able to associated tool-bound permission state with tools that are inherently ephemeral, and don't have something like a persistent ID?

[khushalsagar]

it sounds like the issue is being able to associated tool-bound permission state with tools that are inherently ephemeral, and don't have something like a persistent ID?

From the browser's perspective, tools are ephemeral. The author adds/removes them to the available set with the API described here. Any state associated with a tool is scoped to it's lifetime in this set. This aligns with MCP as well. When a client starts the connection, it uses a "list_tools" command to query the set of tools available. And it can be notified of changes to this set via a "tools_change" notification. The lifetime of the tools is still scoped to the connection.

But from the site (or MCP server's) perspective, tools aren't really ephemeral. A checkout tool may not be enabled based on the current user state but it's there. These 2 states: the site (or MCP server) no longer provides this tool vs the tool is currently disabled are indistinguishable from the browser (or MCP client's) perspective.

This issue is one case where not being able to distinguish these 2 states is a problem since the site wants to store state bound to a combo of tool x agent: "Is the user ok with Agent foo invoking a tool bar without their consent". If you want to minimize user interrupts, you want this to persist across sessions.

There's a couple of API options for this:

1. Site responsibility: The author can trivially use cookies to store this. They also know when a tool is permanently gone so they can keep the cookie state in sync through site updates etc. But they need some way to identify the Agent.

2. Browser responsibility: The site provides a hint for actions which should be user consent gated and the browser manages the permissions. But then the browser needs to know when a tool is permanently gone.

I'm leaning towards 1). Give authors low level primitives that could be useful for multiple use-cases. Add high level primitives for a use-case which becomes very common. So assuming there will be cases where multiple Agents (not necessarily concurrently) can interact with the site, we need to give authors a unique identifier to namespace state associated with each Agent.