Skip to content

feat: Multi-tenant data isolation with OIDC-based tenant extraction #107

Description

@rdwj

Summary

Add hard boundaries between tenants sharing a single agent deployment. Extract tenant identity from OIDC claims, enforce data isolation at the storage layer via Postgres Row-Level Security, and support per-tenant rate limiting and budget enforcement.

Requirements

  • tenant_id as first-class field on every session, trace, feedback, and audit record
  • Tenant extraction from OIDC JWT claims (configurable claim path, e.g., org_id, tenant, sub)
  • Postgres Row-Level Security policies enforcing tenant isolation at the database level
  • Per-tenant rate limiting (configurable requests/minute per tenant)
  • Per-tenant budget limits (extends cost tracking feature)
  • TenantConfig in ServerConfig
  • Tenant context propagated through all server middleware

FIPS Considerations

JWT validation must use RS256 or ES256 (both FIPS-approved) — not HS256 with shared secret. Postgres RLS is SQL-layer, no crypto concerns.

Implementation Notes

Inject tenant_id early in the request pipeline (middleware). All store implementations gain tenant_id columns with RLS policies. Rate limiting via in-memory leaky bucket for single-replica deployments, or Valkey sidecar for multi-replica. The tenant extraction middleware should fail closed — requests without a valid tenant claim are rejected, not assigned a default tenant.

Companion Issues

Companion issues will be filed on fips-agents/gateway-template, fips-agents/fips-agents-cli, and fips-agents/examples.

Size

M

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions