API Key Auth with Scopes & Model Restrictions

[yacosta738]

What

Enhance the existing API key authentication system with fine-grained scopes and model/provider restrictions. API keys should be able to restrict which models, providers, and operations a client can access.

Why

Rook's current API key system is binary — a key grants full access or no access. A production proxy needs:

• Scopes: Limit keys to specific operations (e.g., chat:write, chat:read, providers:read)
• Model restrictions: Allow keys to only use specific models
• Provider restrictions: Allow keys to only route to specific providers
• Read-only keys: For monitoring tools that should not make requests

Basic Spec

API Key with Restrictions

ApiKey {
  id: string
  name: string
  key_hash: string  // HMAC-SHA256 of the actual key
  scopes: Vec<Scope>
  allowed_models: Vec<ModelId>  // empty = all allowed
  allowed_providers: Vec<ProviderId>  // empty = all allowed
  rate_limit: Option<RateLimitRule>
  is_active: bool
  created_at: DateTime
  expires_at: Option<DateTime>
  last_used_at: Option<DateTime>
}

Scope = ChatRead | ChatWrite | ProvidersRead | ProvidersWrite | Admin

Enforcement

• Auth middleware validates key and extracts restrictions
• Request middleware checks scope before routing
• Model restriction checked against CompletionRequest.model
• Provider restriction checked against selected provider
• Violations return HTTP 403 Forbidden

API

• POST /api/api-keys — create key with restrictions
• GET /api/api-keys — list keys (without showing the actual key)
• PUT /api/api-keys/:id — update restrictions
• DELETE /api/api-keys/:id — revoke key
• POST /api/api-keys/:id/rotate — rotate key while keeping restrictions

User Stories

As a system operator
I want to create read-only API keys for monitoring tools
So that monitoring tools can check health without making requests

As a SaaS operator
I want to give each customer their own API key with model restrictions
So that customers cannot access models they haven't paid for

As a developer
I want to know exactly what a key can and cannot do
So that I can debug auth issues quickly

Acceptance Criteria

• API keys support scopes: chat:read, chat:write, providers:read, providers:write, admin
• API keys support allowed_models list (empty = all models)
• API keys support allowed_providers list (empty = all providers)
• Scope violations return HTTP 403
• Model restriction violations return HTTP 403
• Provider restriction violations return HTTP 403
• GET /api/api-keys returns keys without exposing the actual key material
• Expired keys return HTTP 401

[linear-code]

DALLAY-387