The problem You run your own agent: a Slack bot, a service on a VPS, an MCP client you wrote over a weekend. You want it on your files, which on Stream Vessel means your own S3 bucket, where an agent
Markdown supported · ⌘↵ to post
Mike Dabydeen
Deciding at authorize instead of at registration is the right split. Some numbers on how much this matters right now: on Nov 4 we checked 61 official MCP servers that require login, and 36 of them do not advertise CIMD support yet, so most self-registering clients still go through DCR, which is exactly where your per-user list sits. One item I would add to the checklist is the iss parameter in the authorization response. 40 of the same 61 do not return it, and without it a client connected to several authorization servers has no reliable way to tell which one sent a code.
A trusted address can outlive the agent it was added for, and nothing in this design notices. Entries are exact https URIs with no expiry, so the weekend VPS someone retires next spring stays on the list. If its hostname was a CNAME to a cloud resource that later gets released, whoever claims that resource controls the callback. They can register a client with that exact URI and send the user an authorize link, and the consent screen will say the user trusted this address themselves. The typed-host step never comes up, because the address is already trusted.
I'd record the last successful code exchange for each trusted address and show it on the MCP page, then expire entries unused for, say, 90 days, with the same email you send on an addition. Re-trusting costs one typed host, which is cheap next to an entry that changed owners without anyone noticing.