Reference

Security Model

How the gateway authenticates, authorizes and controls every request, at docs depth. For the questionnaire-ready summary, see the Security page.

Identity: gateway keys

Every agent, developer or environment authenticates with its own gateway key (sfgw-...), created in the dashboard's API Keys tab. The key identifies the agent for attribution, and carries its scopes, budget cap and rate limit. See Gateway Keys & Vault.

Request lifecycle

For every request that reaches the gateway, Spineforge:

  1. Authenticates the gateway key and checks the agent's status (a revoked agent is blocked with 403 Forbidden).
  2. Checks the key's scopes against the requested provider and model.
  3. Applies the agent's budget cap and rate limit.
  4. Resolves the real provider key from the encrypted Vault and injects it into the upstream request.
  5. Forwards the request to the provider and streams the response back.
  6. Records the request (tokens, latency and cost) to the audit trail.

Key vault

Master LLM keys (OpenAI, Anthropic, Google Gemini, Groq…) are encrypted and stored in isolated key vaults. They are resolved server-side at request time and are never returned to agents, IDEs or client-side code. Agents and developers only ever hold Spineforge gateway keys.

Revocation: precise semantics

  • Immediate: the status field on the agent record is set to revoked.
  • Immediate: all proxy requests are blocked (403 Forbidden), in-flight and future.
  • Nothing lingers: the agent holds no provider credential, so there is no cached key to expire.
A leaked gateway key can be revoked in one click without rotating anything else. Your provider keys are untouched because they were never in the agent's hands.

Enforcement architecture: inline

Spineforge is explicitly in the data path. Every LLM request is routed through the proxy, so if an agent hits a rate limit, exceeds its budget, or is revoked, the proxy intercepts and blocks the request immediately. The agent stops functioning instantly because it has no direct access to provider keys.

Shadow agent detection

The primary defense is credential custody. If raw keys exist only in Spineforge, unregistered agents have no credential path. This requires the onboarding migration: removing keys from env files, shared vaults, and CI.

Secondary signal today: billing deltas across provider billing portals vs. Spineforge-attributed usage. Significant divergence may indicate out-of-band usage.

Per-key reconciliation against provider Admin APIs is the next phase. Planned Confirmed for OpenAI and Anthropic; Groq has no confirmed Admin API equivalent, unresolved.

Access management & SSO

Dashboard access can use OIDC single sign-on (Google, Okta and Azure AD are supported). Live SAML is on the roadmap. Coming soon See SSO / OIDC.

Data protection & compliance

Data in transit is encrypted with TLS 1.2+ and stored telemetry is encrypted at rest with AES-256. Data-handling modes, Zero-Retention Mode, SOC 2, GDPR and EU AI Act alignment are in progress: the current status of each item is tracked on the Security page and the roadmap.

Next steps