Multi-tenant deployments

[drew]

Problem Statement

OpenShell is currently oriented around local and single-operator gateway deployments. As more teams evaluate OpenShell for shared infrastructure, we need to understand what "multi-tenancy" should mean for the project before implementing tenant-aware APIs, storage, policies, or cluster behavior.

This roadmap ticket collects community requirements for running OpenShell across multiple organizations, teams, projects, or users while preserving the product's core guarantees: safe agent execution, explicit policy boundaries, auditable behavior, and predictable sandbox isolation.

Proposed Design

Treat this issue as the requirements-gathering tracker for multi-tenant OpenShell deployments. Feedback should describe the tenant model, deployment model, isolation expectations, and operational requirements before this becomes one or more implementation issues.

Areas where requirements are needed:

• Tenant model: Should tenants map to organizations, teams, projects, users, customer accounts, or something else?
• Deployment model: Do users expect one shared gateway, one gateway per tenant, a shared Kubernetes cluster, tenant-dedicated clusters, or a mix?
• Identity and access control: What auth providers, SSO/OIDC flows, RBAC roles, service accounts, and admin/operator permissions are required?
• Resource isolation: What boundaries are needed for sandboxes, workspaces, images, GPUs, CPU/memory quotas, storage, network policy, and provider credentials?
• Data ownership and lifecycle: What isolation, retention, export, deletion, and backup behavior is expected for tenant-owned sandbox data and audit records?
• Policy management: Should tenants have inherited default policies, tenant-local policy templates, delegated policy administration, or central approval workflows?
• Provider and inference routing: Should provider credentials and model routes be tenant-scoped, shared by admins, or attachable per sandbox?
• Observability and audit: What per-tenant logs, metrics, OCSF fields, dashboards, and security review workflows are needed?
• Billing or chargeback: Do users need usage accounting by tenant, user, sandbox, model route, GPU, or cluster pool?

Community feedback is most useful when it includes:

• The environment you want to run, such as local workstation, shared lab cluster, enterprise Kubernetes, hosted service, or air-gapped deployment.
• The tenant boundary you need and who administers it.
• The isolation guarantees that are mandatory versus nice to have.
• Current blockers that prevent your team from adopting OpenShell in a shared environment.
• Any compliance, audit, data retention, or access review requirements.