KeyVault.
Docs/Guides/Team onboarding

Team onboarding: shared token policies

Set up KeyVault Edge for your engineering team. Create shared tokens, configure access policies, and make new developer onboarding instant.

Organization setup

KeyVault Edge organizations allow you to share tokens across a team without sharing the underlying real API keys. Team members get access to use sanitized tokens; only token admins can see or modify the underlying key bindings.

  1. 1.Create an organization at Settings → Organization → New
  2. 2.Invite team members by email - they get a dashboard login with their assigned role
  3. 3.Create shared tokens that the whole team can reference
  4. 4.Commit the shared .env file to your repository

Role model

Owner

  • Create and delete tokens
  • View real key references
  • Manage billing
  • Manage team members

Admin

  • Create and delete tokens
  • Manage authorized origins
  • View breach alert logs
  • Invite members

Developer

  • View token list (not values)
  • Copy sanitized tokens for use
  • View their own usage logs

The new developer onboarding workflow

Once your team is on KeyVault Edge, new developer onboarding for API access is reduced to:

New developer setup
# 1. Clone the repo (already contains .env with shared sanitized tokens)git clone https://github.com/yourorg/yourrepo # 2. Install dependenciesnpm install # 3. Start dev server - API calls work immediatelynpm run dev # That's it. No Slack message asking for API keys.# No risk of a real key being shared over an insecure channel.

Token policy recommendations

Create separate tokens for production, staging, and development - different origin lists
Use descriptive token names: 'Production OpenAI - Main App' not 'token1'
Audit token usage monthly in the dashboard - remove unused tokens
When a developer leaves: revoke their personal tokens immediately, shared tokens are unaffected
Enable breach alerts for all production tokens with webhook + email

Environment segregation

.env
# One token per environment, each with its own allowed hosts.# Keep them in each environment's secrets, not in git. # Local .env (gitignored): allowed host localhostOPENAI_KVE_TOKEN=kvt_...dev # Staging secrets: allowed host staging.yourdomain.com# OPENAI_KVE_TOKEN=kvt_...stg # Production secrets: allowed host yourdomain.com# OPENAI_KVE_TOKEN=kvt_...prd
Set up your team Back to docs