MCP-over-ACP: client-held credentials — confirming per-session serverId scoping, plus a Security note

[haowei2000]

Related: MCP-over-ACP RFD · earlier thread #345 · Zulip topic #rfds > MCP-over-ACP

Hi all — we build Cheers, a chat platform where an ACP client (our connector) runs third-party agents (Claude, Codex, Gemini, OpenCode) on a user's host and gives them platform tools over MCP. We've been working through how tool credentials should flow, and MCP-over-ACP looks like exactly the right shape. A few questions and an offer to help.

The pattern we care about

The agent decides what to call; the client decides whether, and with which credential. Today, the only portable option is to put a bearer token into mcpServers[].headers on session/new or session/load.

What we ran into in practice

• Agent-side MCP OAuth didn't work for us. We first tried having each agent authorize itself against our MCP endpoint. Across Claude, Codex, Gemini and OpenCode this turned out to be impractical for most of them. The agent needs a public Client ID Metadata Document (we don't offer dynamic registration) plus an interactive consent step. Our agents run headless on a host, so there is no browser to show it in. Even when the consent URL is relayed to the user, the loopback redirect_uri points at the host, which the user's browser (on another machine) can't reach.
• So we inject a token, and that has costs. Our client now mints a short-lived, host-bound token (OAuth client_credentials) and puts it in mcpServers[].headers. To rotate it, we re-send mcpServers via session/load before every prompt. Whether an agent actually swaps the header for a session that is already live is agent-specific, and we can't verify it uniformly. In practice that pushed us to a 24h TTL.
• One agent process serves many sessions with different authority. A single bot works in many chat channels at once. If the agent did its own OAuth, it would get one token covering all of them, and a prompt injection in one channel could reach another. We mint one token per channel (one per ACP session) instead. Per-session serverId is the clean, portable version of that.
• Mid-call authorization doesn't happen. We haven't seen an agent re-authorize on an MCP 403 insufficient_scope. It surfaces as a generic tool failure, often without the reason reaching the model. We're moving refusals into isError tool results with an explicit next step. URL-mode elicitation isn't a fix here: MCP says servers must not use it to authorize access to themselves, and agent support is still sparse.
• Header-based credentials are visible to the agent process. That's what we most want to remove, and what MCP-over-ACP removes.

With MCP-over-ACP the client can be the provider: it attaches its own credential when forwarding to the real (remote) MCP server, or executes locally, so the agent never holds one. Short-lived or sender-constrained (DPoP) tokens become practical, and so does per-call approval via MRTR.

1. Is per-session serverId the intended way to scope authority?

The RFD says "distinct offerings use distinct server IDs rather than hidden per-MCP-connection catalogs." We read this as: a provider that needs session-specific authority (for us, one chat channel per ACP session) declares a distinct serverId per session and binds the credential to that registration. If that's right, could the Security section say so explicitly? It's the piece that makes client-held credentials safe when one agent process serves several sessions.

2. Proposed non-normative Security text

Credential-holding providers. A provider may hold credentials for downstream services and attach them when executing or forwarding a request; such credentials must not be returned to the caller in results, errors, or metadata. When authority differs between ACP sessions, declare a distinct serverId per session and bind credentials to the registration, not to self-reported request content. Refusals should be returned as tool results the model can read (isError: true) rather than only as transport errors.

Happy to open a PR with this if it's welcome.

What we can contribute

• A second real client+provider implementation (Rust, ACP v1) using per-session server IDs, with test reports against the reference implementation.
• Adapter work: the main blocker for adopting this pattern is agents advertising mcpCapabilities.acp. We'd be glad to help land support in open adapters (e.g. claude-agent-acp, codex-acp) and test the polyfill path for agents without native support.
• Interop findings: which agents re-read MCP headers on session/load, which handle MRTR retries, and so on.

Thanks for the careful design. The request-scoped rewrite made this much easier to reason about.