groq-enterprise-rbac

name	groq-enterprise-rbac
description	Use when you run Groq inference for multiple teams and need per-team model allow-lists, spending caps, rate limits, and key rotation — because Groq API keys have no built-in scopes, so access control must live in your gateway. Configure Groq organization management, API key scoping, spending controls, and team access patterns. Trigger with phrases like "groq organization", "groq RBAC", "groq enterprise", "groq team access", "groq spending limits", "groq multi-team".
allowed-tools	Read, Write, Edit
version	1.11.0
license	MIT
author	Jeremy Longshore <[e-mail]>
tags	["saas","groq","rbac"]
compatibility	Designed for Claude Code, also compatible with Codex and OpenClaw

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
   }  ;