Skip to content

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

@rdwj

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions