There was a working design for connecting an agent to your Develosaur account, and it shipped ahead of everything else in the plan because it was the fastest thing to build: generate a key on a settings page, paste it into your agent's config, done. I killed it before it ever became a user-facing feature.
Develosaur's only user-facing way to connect an agent to your account is OAuth. One browser popup, one sign-in, done, and you never see a credential to manage.
The design I said no to
The bearer-key plan was not a bad engineering call. It is independently shippable ahead of a whole OAuth integration, it is how a lot of developer tools hand out access, and "paste your key" gets someone a real, permanent board today instead of after a bigger build. As sequencing, it was correct.
As a product, I rejected it. My own reasoning: I do not always know where my own API keys are. If I cannot reliably find mine, I am not going to build a product that assumes a user will locate one, copy it correctly, and paste it somewhere without a typo, and I am not going to staff a support queue that spends its time answering "where do I put this."
What is still true underneath
Saying no to the user-facing key did not remove the need for the plumbing behind it. An OAuth access token still has to resolve to a specific signed-in user on every request the agent makes, and the server session handling still has to know which account it is acting for. That identity layer exists and has to be correct. What changed is that it never becomes something you manage. You complete a sign-in once; everything after that is invisible.
The actual flow
Add Develosaur in your agent's connector settings, or for Claude Code:
claude mcp add --transport http develosaur https://mcp.develosaur.com/v1/user/mcp
A browser consent popup opens, you sign in with the account you already have, you approve, and that is the entire auth story. One moment of friction, never repeated. There is a separate, no-account path for trying the product with nothing to sign into at all; how that one works is covered in Agentic Workflow MCP.
What sign-in buys beyond convenience
Because identity already comes from the sign-in, sharing a board never needed its own separate system. An agent acting on your behalf sees exactly what you see: your own projects, plus anything shared with you, and nothing else. There is no second permission model to keep in sync with the first, no invite-key scheme running alongside the account system, no way for the two to drift apart because there is only one.
It is also the actual security boundary. A pasted key is a string that grants access to whoever holds it: in a git commit, a screenshot in a support ticket, a leaked .env file. There is no equivalent string here. The boundary is the consent screen you approved once, not a secret you are trusted to keep secret afterward.
The faster feature was still on the table when I said no to it. It would have worked. It also would have made every user responsible for a credential I could not promise they would ever be able to find. More on how the rest of the trust model holds together is on the how-it-works page, and more of these are on the blog.