Groq Enterprise Access Management

Overview

Manage team access to Groq's inference API through API key strategy, model-level routing controls, spending limits, and usage monitoring. Groq uses flat API keys (gsk_ prefix) with no built-in scoping -- access control is implemented at the application layer, in a gateway that sits between your teams and Groq.

Groq Access Model

• API keys are per-organization, not per-user
• No built-in scopes -- every key has full API access
• Rate limits are per-organization, shared across all keys
• Spending limits are configurable in the Groq Console
• Projects allow creating isolated API keys with separate limits

Prerequisites

• A Groq organization with Console access (console.groq.com) and billing configured.
• Permission to create Groq Projects — one per team/service, each yielding its own gsk_ key.
• A secret manager (AWS Secrets Manager, GCP Secret Manager, Vault, etc.) to store per-team keys.
• A gateway/service layer (Node/TypeScript in these examples) that every team's traffic passes through — Groq enforces nothing per-team, so your gateway is the control point.
• groq-sdk and p-queue installed if you use the reference gateway.

Instructions

Access control is enforced in your own gateway. The full, copy-paste implementation for every step lives in references/implementation.md; the high-level flow:

1. API key strategy — one Groq Project (and key) per team/environment, named {team}-{environment}-{purpose}. Register keys in a lookup:

   // Key naming convention: {team}-{environment}-{purpose}
   const KEY_REGISTRY = {
     "chatbot-prod":    "gsk_...",  // Project: chatbot-production
     "chatbot-staging": "gsk_...",  // Project: chatbot-staging
     "analytics-prod":  "gsk_...",  // Project: analytics-production
   } as const;
   

2. Model access control — define a per-team config (allowedModels, maxTokensPerRequest, monthlyBudgetUsd, rateLimitRPM) and a validateRequest(team, model, maxTokens) guard that throws before any unauthorized model or oversized request reaches Groq.

3. API gateway — groqGateway(team, messages, model, maxTokens) validates permissions, checks the monthly budget, rate-limits per team via p-queue, calls Groq with the team's key, and records usage.

4. Spending controls — set an org-level cap + alerts in the Groq Console (50/80/95%, auto-pause), and track application-level per-team spend with recordTeamUsage, which logs threshold alerts.

5. Key rotation — zero-downtime rotation: create a new key in the same Project, deploy alongside the old key, update the secret manager, restart, monitor 24h, then delete the old key.

See references/implementation.md for the complete code for each step.

Output

Applying this skill produces a working per-team access layer in front of Groq:

• A key registry mapping each team/environment to its own Groq Project key.
• A TEAM_CONFIGS policy object — the source of truth for which models, token ceilings, budgets, and rate limits each team gets.
• A gateway function that rejects unauthorized model/token/budget requests before they reach Groq and rate-limits per team.
• Per-team spend tracking with 80%/95% threshold alerts, plus a weekly cost/token report table.
• A documented key-rotation runbook for zero-downtime credential changes.

Error Handling

Examples

Two worked examples — a weekly per-team usage dashboard and a request that gets blocked by the model allow-list — are in references/examples.md.

The gateway rejects an out-of-scope model before it ever bills Groq:

// analytics is scoped to llama-3.1-8b-instant only
await groqGateway("analytics", messages, "llama-3.3-70b-versatile", 512);
// throws: "Team analytics not authorized for model llama-3.3-70b-versatile"

Resources

• Groq Projects
• Groq Spend Limits
• Groq Rate Limits
• Groq API Keys
• Full implementation walkthrough
• Worked examples
• For migration strategies, see the groq-migration-deep-dive skill.