Stop sharing your OpenAI API key with your team

A developer built Melony, a hosted team chat product for agents built on the OpenAI Agents API or Claude Managed Agents, after concluding that sharing a single API key across a team grants account-wide access rather than access to one agent. The architecture routes all browser traffic through a server-side proxy that enforces membership and daily limits, stores the platform key server-side, and keeps a lightweight session access index so users see only their own and shared sessions, returning 404 rather than 403 to prevent probing. The developer also recommends denying tool calls awaiting approval instead of building an approval UI, and warns that teams should weigh the ongoing maintenance of such a layer against simply sharing a key.

You built an agent on the OpenAI Agents API, or on Claude Managed Agents. It works. You show it to the support lead and they say: "Can my team use this tomorrow?" The fastest answer is to paste the API key into Slack along with a script, and let everyone run it. Please don't. Here's why, and what I learned building the alternative. A shared API key isn't access to one agent . It's access to your account. .env files, screenshots and someone's personal laptop. Each copy is a liability. What you actually want is to share the agent , not the key . When I started, I thought it was a text box and a streaming response. It turned out to be eight things: None of these is hard on its own. Together they're a product. The heart of it is a small proxy. The browser talks only to your API. Your API checks who's calling, then calls the platform with the key: // Pseudocode: the shape of every chat request app.post "/v1/chat", requireSignedInUser, async req, res = { const agent = await db.getAgent req.body.agentId ; // 1. Membership: return 404, not 403, so non-members can't probe which agents exist if await db.isMember agent.id, req.user.id return res.sendStatus 404 ; // 2. Limits, enforced here, not in the UI if await overDailyLimit req.user.id return res.sendStatus 429 ; // 3. The key comes from server-side storage and never leaves this process const apiKey = await secrets.get agent.id ; // 4. Call the platform and stream a normalized event format back to the browser const events = platformFor agent .send { apiKey, agent, sessionId: req.body.sessionId, message: req.body.message } ; streamAsSSE events, res ; } ; A few rules I'd now treat as non-negotiable: This one took me a while to notice. Hosted agent platforms run sessions for your API key , not for your users. They don't track which person started which session. So if you want "my chats are private", you need your own small access index : // One row per session. This is not the conversation; the messages stay on the platform. type SessionAccess = { sessionId: string; // the platform's session id ownerId: string; // your user id shared: boolean; // visible to everyone on the agent? createdAt: Date; }; The sidebar lists sessions you own plus the shared ones. Any request for a session you can't see returns 404 before calling the platform. That's also why I don't store messages at all: the platform already does, and keeping a second copy is just more data to protect. Both platforms support tools, and some setups pause a tool call until someone approves it. If your chat UI has no approval flow, that session just waits forever. My fix: don't build an approval UI. Deny calls that are waiting for approval, with a clear message pointing at the agent's permission policy. Configure permissions where the agent lives, on the platform, and keep the chat UI simple. If the chat is part of a customer-facing product , build it. You'll want your own auth, branding and billing anyway. If the users are your own team , think twice. Everything above is maintenance you'll carry as both platforms change. Disclosure: I went through all of this and turned it into Melony https://melony.dev , a hosted team chat for agents built on the OpenAI Agents API or Claude Managed Agents. You connect the agent with its key once, invite teammates by email, and the key stays on the server. It's free, and the security page https://melony.dev/security/ lists exactly what it stores. But the pattern above works whether you use it or build your own. How are you sharing agents with your team right now? A shared key, an internal tool, or something else? I'd like to hear what's working for you.