Inside Our Membership System: How We Gave Every User Their Own Keys to the AI Agent Kingdom

TL;DR

• We shipped a full membership system: per-user credentials, role-based agent access, BYOK keys, and permission-gated knowledge bases.
• Credentials are bcrypt-hashed, projected into K8s Secrets, and hot-reloaded by a sidecar — revocation takes seconds, zero downtime.
• This is how identity works inside a cyborgenic organization where humans and AI agents share real roles.

The Dirty Secret of Multi-User Agent Platforms

Your AI agents have job titles, cloud credentials, and production access — but everyone on your team logs into them with the same password. That is not a team. That is a security incident waiting to file itself.

Most multi-agent platforms are single-tenant nightmares dressed up in team-collaboration clothing. One API key floats around a Slack channel like a house key under the doormat. When someone leaves? Good luck rotating that key across 14 agents and 6 integrations at 11pm on a Friday.

A cyborgenic organization — where AI agents hold real roles alongside humans — cannot run on shared passwords and honor-system access. We hit this wall building GenBrain's own agent fleet. Marketing, engineering, operations: each agent needed identity-aware, role-gated, auditable access scoped to individual users.

So we built it. Three sprints. A full membership system — from invitations and role-based access to per-user knowledge bases that follow you across agents. Here is exactly how it works under the hood.

Sprint 1: Invitations, Roles, and Per-User Agent Access

The foundation is straightforward: org owners can invite users and assign them one of four roles.

• Owner — full control over the organization, billing, and all agents
• Admin — manages agents, members, and configuration
• Developer — interacts with assigned agents, deploys changes
• Viewer — read-only access to assigned agent outputs

Invitations land in Firestore subcollections (members, invites, credentials), and each invite carries its role assignment. Nothing fancy here — just clean data modeling that does not require a PhD to debug at 2am.

The real work was in agent assignment. We built a many-to-many relationship between users and agents via an agentPermissions model. An admin can assign User A to agents 1, 3, and 7, while User B only gets access to agent 3. This is not "everyone sees everything" — it is precise, per-user, per-agent control.

Per-User Terminal Authentication

This is where things got interesting.

Every agent at GenBrain runs a ttyd web terminal — it is how users interact with agents in real time. Previously, each agent had a single set of shared basic-auth credentials. If you had the password, you were in. If you shared it accidentally, everyone was in.

We replaced that with per-user credentials. When a user is assigned to an agent, they get their own basic-auth username and password for that agent's terminal. Under the hood:

1. Credentials are stored as bcrypt hashes in Firestore — never plaintext, never reversible.
2. A projection layer syncs those hashes into Kubernetes Secrets, one per agent.
3. An auth proxy sidecar sits in front of each ttyd instance, reading credentials from the mounted Secret.
4. The sidecar watches for file mtime changes — when credentials update in Firestore and project into K8s, the proxy picks them up without a pod restart.
5. A legacy fallback path ensures existing single-credential agents keep working during migration.

The result: revoking a user's access means deleting their credential in Firestore. Within seconds, the K8s Secret updates, the sidecar reloads, and that user's password stops working. No pod restarts. No downtime. No "did we remember to rotate that one?"

Sprint 2: BYOK, Audit, and Organizational Visibility

With identity in place, we tackled the features that only matter once you know who is doing what.

Bring Your Own Key (BYOK) lets users attach their own API keys — for LLM providers, external services, whatever the agent needs. Keys are scoped to the user, not the org. User A's OpenAI key is not visible to User B, and agents use the key of the user who triggered the action. This is critical for teams where different departments have different billing accounts or rate limits.

User awareness means every action in the system now carries a user identity. Agents know who is talking to them. Logs know who triggered a deployment. This is not just about security — it is about context. An agent that knows it is talking to a developer gives different responses than when it is talking to a viewer.

Organization visibility controls let admins decide what is public and what is private across the org. Some agents are internal-only. Some knowledge bases are org-wide. Some are personal. The visibility layer enforces these boundaries consistently, whether you are hitting the API, the web UI, or the terminal.

Audit capabilities tie it all together. Every membership change, every agent assignment, every credential rotation — logged, timestamped, attributed to a user. When compliance asks "who had access to the production agent on March 15th?" you have the answer in seconds, not hours.

Sprint 3: Knowledge Bases That Follow the User

This is the sprint we are most excited about.

AI agents are only as good as the context they have. And until now, context was either global (everyone sees everything) or nonexistent (the agent starts fresh every time). Neither works for a real team.

We built permission-gated knowledge bases on top of our existing Neo4j wiki space infrastructure. Here is how they work:

Users create knowledge bases scoped to themselves (personal) or to the entire org. A developer might create a personal knowledge base with their team's API conventions and deployment runbooks. An admin might create an org-wide knowledge base with company policies and brand guidelines.

Knowledge bases are assigned to agents — but only agents the user has access to. A developer who can access agents 1 and 3 can assign their knowledge base to those agents, but not to agent 7. Org admins and owners can assign to any agent.

We exposed this through five MCP tools:

• create_my_wiki — spin up a new knowledge base (personal or org-scoped)
• list_my_wikis — see all knowledge bases you own or have been granted access to
• assign_wiki_to_agent — attach a knowledge base to an agent you have permissions for
• share_wiki_with_user — grant another user access to your knowledge base
• revoke_wiki_grant — remove a user's access to a knowledge base

The permission model is layered. Sharing a knowledge base with a user does not automatically give them access to the agents it is attached to. And assigning a knowledge base to an agent does not expose it to users who lack access to that agent. Both conditions must be met.

This means a marketing manager can build a brand-voice knowledge base, share it with the content team, and assign it to the marketing agent — all without the engineering team ever seeing it. Meanwhile, the engineering lead can maintain a separate architecture knowledge base on the same agent, visible only to developers.

The Security Model

Let us be direct about the security architecture because it matters.

Credentials never exist in plaintext at rest. Bcrypt hashes in Firestore, projected into K8s Secrets, read by a sidecar that never logs the values. The auth proxy validates credentials on every request — no session tokens to steal, no cookies to hijack.

Permission checks are enforced at the data layer, not just the UI. Even if someone crafts a direct API call, the agentPermissions model gates every operation. No permission, no access — regardless of how you ask.

BYOK keys are user-scoped and encrypted. Your API key is your API key. It is not visible to other users, not shared across agents, and not accessible to org admins.

Audit logs are append-only. You cannot delete or modify audit entries. When something goes wrong — and something always eventually goes wrong — the trail is intact.

What's Next

The membership system is live, but we are not done. On the roadmap:

• Granular agent permissions — beyond assign/unassign, controlling what actions a user can trigger on an agent (deploy, configure, read-only observe)
• Team-scoped knowledge bases — in addition to personal and org, a middle layer for department-level context
• SSO and SAML integration — because enterprises will ask, and they should
• Cross-org agent sharing — letting two organizations share an agent with isolated knowledge bases and independent audit trails

We are building this in public because the cyborgenic organization model — where AI agents hold real roles alongside humans — is where work is headed. That model does not work without real identity, real permissions, and real accountability.

Try It Yourself

GenBrain's membership system is available now. If you are running AI agents for your team and tired of the shared-password, single-tenant status quo, we built this for you.

Build your own cyborgenic organization at agent.ceo — and give every person on your team their own keys to the kingdom.