When an agent lives in a shared chat, it can make a deceptively human mistake: treat the person who set it up as the person whose account every tool should use. In the openclaw/openclaw repository, OpenClaw has added a different option. Its new per-requester OAuth mode lets each authenticated sender in a trusted shared channel connect a separate account to an HTTP MCP server.
That matters when a bot is a common front door to personal systems: a shared channel can ask an agent to search documents, schedule work, or call another connected service without silently making every request look like it came from the operator. The implementation keys requester credentials to the channel, agent account, and sender; the configuration reference describes that as a choice between the existing shared owner and a per-requester owner.
The agent stays common; the account does not
The shape is deliberately narrow. An operator configures an HTTP MCP server with oauth.identity: "per-requester" and supplies a reachable gateway.publicOrigin. A sender who tries a tool before connecting gets a sign-in link; the provider returns through /oauth/mcp/callback, then the sender retries the call with their own account. The MCP guide shows the full public configuration and says the older command-line login remains for shared operator credentials.
The code does more than rename a setting. The commit adds state-keyed callback correlation, keeps credentials scoped to the requester tuple, and exercises a two-user flow through a real self-hosted Gateway callback. It also keeps per-requester servers out of static and scheduled runtimes, where there is no sender identity to attach. That is the useful design pressure: credential ownership is part of the request context, not a property of the agent alone.
Not a private handoff—and not the new default
The first reading of this change as a blanket shared-channel safety fix does not hold. shared remains the default, and per-requester identity is opt-in. More importantly, the guide calls its sign-in links single-use bearer links and says to use the flow where trusted senders are mutually trusted. It changes which account the tool uses; it does not turn a channel into a private authorization surface or decide who belongs there.
Still, the boundary is a useful one to make explicit. Teams that put an agent in a shared room can now ask a specific operational question: should this room share a service account, or should each sender bring their own? The next signal is a release and public tests of the hard cases—especially a handed-off link, a changed channel membership, and a sender who should never have been allowed to connect in the first place.