Lab 01 — Multi-Tenant Agent Gateway

Phase 13 · Lab 01 · Phase README · Warmup

The problem

An enterprise agent platform serves many customers on shared infrastructure, and the cardinal rule is isolation: tenant A must never touch tenant B's data — including the AI-specific leak channels (a shared vector index, a prompt cache, agent memory). Build the gateway that enforces it: signed-token auth, RBAC, tenant-scoped data + vector isolation, per-tenant secrets, token-bucket quotas, and an audit log. Pure stdlib, deterministic.

What you build

PieceWhat it does
issue_token / verify_tokenJWT-shaped signed tokens (hmac); tenant comes from the token, not the request
authorizeRBAC, default-deny
TenantStorerow-level scoping — a query is always filtered to the caller's tenant
VectorIndexper-tenant namespaces — the #1 multi-tenant AI leak channel, closed
PromptCache / AgentMemorytenant-keyed so a cache hit / memory can't cross tenants
SecretStoreper-tenant secrets only; never cross-tenant
RateLimiterper-tenant token bucket (injected clock), never negative
AuditLog + redactappend-only who/what/tenant, secrets redacted
Gatewayverify → authorize → rate-limit → scoped access → audit

File map

FileRole
lab.pyyour implementation (fill the # TODOs)
solution.pyreference + a main() (two tenants; A denied B's rows/vectors/secret; tampered token; quota)
test_lab.py35 tests: tokens, RBAC, isolation, vector namespaces, cache/secret scoping, quotas, audit
requirements.txtpytest only

Run it

pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v
python solution.py

Success criteria

  • A tampered/expired token is rejected; the tenant is derived from the signed token, never the request body.
  • authorize default-denies; a tenant-admin can't act on another tenant's resource.
  • TenantStore, VectorIndex, PromptCache, AgentMemory, and SecretStore all refuse cross-tenant access — the shared-index leak is closed.
  • The rate limiter refills, denies when empty, and never goes negative; the audit log redacts secrets.
  • All 35 tests pass under both lab and solution.

How this maps to the real stack

  • Tokens ≈ real OAuth2/OIDC + JWT (short-lived, rotated); authorize ≈ RBAC/ABAC.
  • TenantStore scoping ≈ Postgres row-level security; VectorIndex namespaces ≈ per-tenant Pinecone/pgvector namespaces (the isolation most teams get wrong first).
  • SecretStore ≈ a vault with per-tenant custody / BYOK; RateLimiter ≈ per-tenant quotas (noisy-neighbor isolation); AuditLog ≈ SOC2-grade append-only audit.
  • The whole thing ≈ the silo/pool/bridge multi-tenant SaaS patterns, applied to an agent platform.

Limits. Real platforms add encryption at rest/in transit, data-residency, per-tenant fine-tuned adapters (multi-LoRA), and compliance evidence; the isolation mechanisms are exactly these.

Extensions (your own machine)

  • Add encryption at rest (per-tenant keys) and residency tags.
  • Add per-tenant fine-tuned adapters (multi-LoRA routing) and prove they don't co-mingle.
  • Thread this gateway in front of the Phase 17 capstone platform.

Interview / resume signal

"Built a secure multi-tenant agent gateway — signed-token auth (tenant from the token, not the request), RBAC default-deny, row-level and vector-namespace isolation closing the shared-index leak, per-tenant secrets and quotas, and a redacted audit log — the enterprise isolation obligation in code."