[GH-ISSUE #10] Add multi-tenant support #6

New issue

Open

opened 2026-10-29 14:18:16 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:18:16 +00:00

Owner

Originally created by @yingdi-shan on GitHub (Jul 27, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/10

Summary

AgentENV should add first-class multi-tenant support so one deployment can safely serve multiple teams, organizations, or projects without relying on ad hoc metadata filters or external routing conventions.

Today the API authentication path accepts several auth header shapes, but src/api/impls/auth.rs only checks that a header is present and returns an empty Claims value. Runtime resources such as sandboxes, snapshots, templates, aliases, proxy routes, and scheduler bindings are not scoped by a tenant identifier. This is acceptable for local development and trusted single-tenant deployments, but it is not enough for shared service deployments.

Motivation

A multi-tenant AgentENV deployment needs to prevent one tenant from seeing, modifying, resuming, deleting, or proxying into another tenant's resources. It also needs tenant-aware limits and observability so operators can allocate capacity fairly and debug tenant-specific workloads.

Without first-class tenant identity:

API keys/tokens cannot map to an authorization scope.
Sandbox list/get/delete/resume/pause operations are global by ID.
Snapshot/template aliases are global and can collide across tenants.
Template and snapshot catalogs cannot cleanly distinguish public/shared resources from private tenant resources.
Gateway/scheduler routing can bind only by sandbox ID, not by tenant ownership.
Quotas and usage accounting can only be implemented outside AgentENV.

Proposed scope

Introduce a typed tenant identity model, for example TenantId, and include it in authenticated request claims.
Replace presence-only auth with a pluggable auth/claims extraction layer that can support at least:
- local development compatibility with dummy credentials,
- static API-key-to-tenant mapping from config,
- forwarded identity headers from a trusted gateway or auth proxy,
- future JWT/Supabase validation without changing downstream resource APIs.
Store tenant ownership on tenant-owned resources:
- sandboxes and paused sandbox metadata,
- snapshots and template build records,
- template aliases / snapshot aliases,
- attached drives or future persistent volumes where applicable,
- scheduler sandbox-to-node bindings.
Enforce tenant scoping on all user-facing APIs:
- list endpoints return only resources visible to the caller,
- get/update/delete/lifecycle operations reject cross-tenant access,
- alias resolution is tenant-scoped unless the target is explicitly shared/public,
- proxy and WebSocket paths validate tenant ownership before routing.
Define sharing semantics:
- private resources visible only to the owning tenant,
- optional public/shared templates or snapshots,
- explicit rules for using shared base templates while publishing derived private snapshots.
Add tenant-aware quotas and limits:
- max running sandboxes,
- CPU/memory/disk allocation,
- snapshot/template storage,
- create/start rate limits where practical.
Include tenant fields in observability/admin surfaces while keeping admin APIs able to inspect global state.
Document migration and compatibility behavior for existing single-tenant deployments.

Originally created by @yingdi-shan on GitHub (Jul 27, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/10 ## Summary AgentENV should add first-class multi-tenant support so one deployment can safely serve multiple teams, organizations, or projects without relying on ad hoc metadata filters or external routing conventions. Today the API authentication path accepts several auth header shapes, but `src/api/impls/auth.rs` only checks that a header is present and returns an empty `Claims` value. Runtime resources such as sandboxes, snapshots, templates, aliases, proxy routes, and scheduler bindings are not scoped by a tenant identifier. This is acceptable for local development and trusted single-tenant deployments, but it is not enough for shared service deployments. ## Motivation A multi-tenant AgentENV deployment needs to prevent one tenant from seeing, modifying, resuming, deleting, or proxying into another tenant's resources. It also needs tenant-aware limits and observability so operators can allocate capacity fairly and debug tenant-specific workloads. Without first-class tenant identity: - API keys/tokens cannot map to an authorization scope. - Sandbox list/get/delete/resume/pause operations are global by ID. - Snapshot/template aliases are global and can collide across tenants. - Template and snapshot catalogs cannot cleanly distinguish public/shared resources from private tenant resources. - Gateway/scheduler routing can bind only by sandbox ID, not by tenant ownership. - Quotas and usage accounting can only be implemented outside AgentENV. ## Proposed scope 1. Introduce a typed tenant identity model, for example `TenantId`, and include it in authenticated request claims. 2. Replace presence-only auth with a pluggable auth/claims extraction layer that can support at least: - local development compatibility with dummy credentials, - static API-key-to-tenant mapping from config, - forwarded identity headers from a trusted gateway or auth proxy, - future JWT/Supabase validation without changing downstream resource APIs. 3. Store tenant ownership on tenant-owned resources: - sandboxes and paused sandbox metadata, - snapshots and template build records, - template aliases / snapshot aliases, - attached drives or future persistent volumes where applicable, - scheduler sandbox-to-node bindings. 4. Enforce tenant scoping on all user-facing APIs: - list endpoints return only resources visible to the caller, - get/update/delete/lifecycle operations reject cross-tenant access, - alias resolution is tenant-scoped unless the target is explicitly shared/public, - proxy and WebSocket paths validate tenant ownership before routing. 5. Define sharing semantics: - private resources visible only to the owning tenant, - optional public/shared templates or snapshots, - explicit rules for using shared base templates while publishing derived private snapshots. 6. Add tenant-aware quotas and limits: - max running sandboxes, - CPU/memory/disk allocation, - snapshot/template storage, - create/start rate limits where practical. 7. Include tenant fields in observability/admin surfaces while keeping admin APIs able to inspect global state. 8. Document migration and compatibility behavior for existing single-tenant deployments.

bsakaguchi added the

enhancement

label

2026-10-29 14:18:16 +00:00

bsakaguchi referenced this issue

2026-10-29 14:20:26 +00:00

[PR #76] [1/4] feat(web): scaffold control-plane console and deploy wiring #160

bsakaguchi referenced this issue

2026-10-29 14:20:27 +00:00

[PR #77] [CLOSED] [2/4] feat(web): Gateway connection settings and session cookies #161

bsakaguchi referenced this issue

2026-10-29 14:20:28 +00:00