cd /news/ai-agents/stop-sharing-your-openai-api-key-wit… · home › topics › ai-agents › article
[ARTICLE · art-153199] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

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.

by read3 min views2 publishedOct 19, 2026

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 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, 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 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.

── more in #ai-agents 4 stories · sorted by recency
── more on @melony 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/stop-sharing-your-op…] indexed:0 read:3min 2026-10-19 · —