agentsclimarketplace

Groq enterprise rbac

Skill jeremylongshore/claude-code-plugins-plus-skills/plugins/saas-packs/groq-pack/skills/groq-enterprise-rbac

425 plugins, 2,810 skills, 200 agents for Claude Code. Open-source marketplace at tonsofskills.com with the ccpi CLI package manager.

Install
npx -y skills add jeremylongshore/claude-code-plugins-plus-skills --skill groq-enterprise-rbac

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

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".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.5 KB, as published. Nobody here has run it

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

IssueCauseSolution
429 rate_limit_exceededOrg-level RPM/TPM hitTeams share org limits; reduce aggregate volume
401 invalid_api_keyKey deleted or rotatedUpdate secret manager, restart services
Budget exhaustedMonthly cap reachedIncrease cap or wait for billing cycle reset
Wrong model usedNo server-side enforcementValidate model against team config before calling Groq

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.