Stop sharing your OpenAI API key with your team

Dato Daraselia — Mon, 19 Oct 2026 19:30:47 +0000

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.

Why a shared key goes wrong

A shared API key isn't access to one agent. It's access to your account.

It often reaches more than one agent. Depending on how the key is scoped, it can reach other agents, other models and other projects. You meant to share one thing and handed over many.
You can't revoke it for one person. Someone leaves the team? Rotate the key, and now everyone's setup breaks at the same time.
It spreads. It ends up in Slack history, .env files, screenshots and someone's personal laptop. Each copy is a liability.
No per-person limits. One runaway loop on someone's machine, and the whole bill lands on you.
No privacy between teammates. Everyone shares one identity, so there's no "my chats" versus "your chats".

What you actually want is to share the agent, not the key.

What "sharing an agent" really needs

When I started, I thought it was a text box and a streaming response. It turned out to be eight things:

Sign-in for people who don't have platform accounts.
Membership per agent: who can use it, who can invite, who owns the key.
A server-side proxy, so the key never reaches a browser.
Streaming: text, plus tool activity, so people can see what the agent is doing.
Chat history per person.
Private and shared chats, with clear rules about who can see, unshare and delete them.
Server-enforced limits. Limits that exist only in the UI aren't limits.
Platform quirks: environments and vaults on Claude Managed Agents, the hosted sandbox and Vault on OpenAI, and tool calls that pause waiting for approval.

None of these is hard on its own. Together they're a product.

The core pattern: the key lives on the server, the user only sees the agent

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:

The key is never in a response body: not in JSON, not in an SSE event, not in an error message.
Keep the key out of the database the client can read. If your frontend reads documents directly (Firebase and friends), store the key somewhere the browser cannot reach at all, and deny access to it in the security rules too.
One key per agent, held by its owner. The owner pays, the owner rotates it, and nobody else ever holds it.

The surprise: the platforms don't know who is chatting

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.

Tool approvals will hang your UI

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.

Build it, or don't

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.

Solving AI fragmentation problem via Slack-like platform

Dato Daraselia — Tue, 07 Apr 2026 18:51:34 +0000

We believe that 2026 must be the year of coordination and orchestration of AI agents so we invest our spare time to build something really amazing!

Would love to hear your feedback!

Here is a (temp) source: https://github.com/meetopenbot/openbot/tree/refactor/slack

DEV Community: Dato Daraselia