one-org-per-VMNo customer organization shares a shell or runtime VM with another customer organization, even when multiple branch workspaces are active.
Security
Security starts with organization-exclusive VMs.
EnvForge treats customer code, dev URL traffic, and agent activity as scoped product surfaces. Auth0 for identity, EnvForge authorization, organization-exclusive VMs, SSM SecureString/KMS for workspace secrets, minimal IAM on runtime hosts, signed dev sessions, optional Tailscale private access, configurable root policy, audit logs, and awake-only runtime boundaries all stay visible to the team operating the workspace.
First-release trust
First-release trust contract.
These are the public commitments the first release needs to make plain before a buyer asks for deeper architecture detail.
Auth0 identifies; EnvForge authorizesAuth0 establishes the user session and login context. EnvForge checks membership, roles, workspace permission, signed dev link issuance, root policy, and billing visibility.
signed dev.envforge.ai URLsReviewer access is a signed app session for one service, workspace, organization, and expiration. It does not open SSH, logs, secrets, root, private consoles, or runtime admin.
awake runtime meterSleep stops paid service capacity, but Auth0, audit history, signed-link policy, root policy, and workspace metadata stay governed.
Responsibility split
The security page should say who owns each boundary.
Production-facing security copy is stronger when it separates product controls from customer decisions and names what a signed dev link will never grant.
Organization-exclusive VM placement, signed dev gateway checks, Auth0 session mapping, EnvForge product authorization, runtime sleep state, and platform-secret separation are product controls.
Repository selection, envforge.yml review, workspace role assignment, root policy choice, Tailscale policy, customer-cloud resource ownership, and cleanup decisions stay with the customer organization.
Readiness receipts, usage receipts, signed dev link scope, resource modes, and command history are the shared artifacts support, operators, developers, and agents can inspect.
SSH, raw logs, secrets, private consoles, root elevation, runtime admin, and customer-cloud credentials are never granted by a reviewer dev URL.
Controls
The security model is product-visible.
Operators should see the same boundaries the platform enforces: runtime placement, dev link scope, root policy, private access, and secret injection are explicit settings rather than hidden host assumptions.
Shell and runtime VMs are assigned to one customer organization. Workspaces can share the owning organization boundary, but EnvForge never packs another customer organization onto the same VM.
Auth0 proves identity, but EnvForge owns authorization. Organization membership, product roles, workspace access, dev link scope, and root policy are checked before any workspace surface opens.
Platform secrets stay in the control plane and are never copied into shell or runtime hosts. Workspace secrets are referenced through SSM SecureString paths protected by KMS and injected only into declared runtime inputs.
Signed dev links open web, same-origin /api, assets, and WebSockets while SSH, secrets, logs, MinIO console, Mailpit, and runtime admin stay private by default.
Teams can route shell or private runtime services through tagged Tailscale devices without turning private operational ports into public dev URLs.
Root access is a configurable organization policy: disabled, approved break-glass, or workspace elevation for root-heavy work. Signed dev sessions never inherit it.
Runtime isolation does not depend on billing state. Sleep stops metered service CPU and memory while organization policy, signed-link state, and audit history remain in force.
Runtime hosts use least-privilege IAM for declared workspace resources. Broad platform roles and secret-management permissions stay on EnvForge control-plane services.
Identity and authorization
Auth0 authenticates; EnvForge decides what that identity can do.
EnvForge does not outsource authorization to the identity provider. Product checks live in EnvForge so organization membership, workspace role, signed dev link issuance, private access, and root elevation all use the same policy model.
Auth0 authenticationUsers authenticate through Auth0 for CLI and dashboard sessions. Auth0 establishes who the user is; it does not grant workspace access by itself.
EnvForge-owned rolesEnvForge evaluates organization membership, project role, workspace permission, signed dev link issuance rights, and root policy before allowing an action.
service / workspace / orgSigned dev sessions and runtime actions carry the target service, workspace, and organization so access stays scoped to the selected branch environment.
Root access
Root access stays governed from request to closeout.
EnvForge does not treat root as a hidden host default. Organizations decide whether root is disabled, break-glass only, or available in an approved workspace elevation mode, then every exception follows a visible approval path.
- Default
Root starts closed
Root stays disabled unless the organization policy allows break-glass access or a dedicated workspace elevation mode.
- Request
The reason is recorded first
A developer or agent names the package install, host repair, or debugging task that cannot be expressed in envforge.yml or a base image update.
- Approval
Elevation is scoped and time-boxed
An admin approves the workspace, requester, expiration window, and allowed elevation mode before the shell can run root-level work.
- Closeout
The workspace returns to policy
EnvForge records the requester, approver, workspace, start and end times, then drops the workspace back to its normal root posture.
Secret delivery
Secrets move by reference, not by dev link.
EnvForge separates platform credentials from workspace runtime inputs. SSM SecureString is the handoff point for workspace secrets, while signed browser sessions, route labels, logs, and public dev links never receive raw values.
SSM SecureStringWorkspace secret values live in SSM SecureString parameters protected by KMS. Raw values do not appear in dev sessions, route labels, or audit rows.
envforge.yml inputsServices ask for inputs such as DATABASE_URL or API tokens by name, keeping secret contracts reviewable beside the code without committing values.
Runtime wakeWhen a workspace runtime wakes, EnvForge resolves the approved references and injects values only into the declared service environment.
Metadata onlyAudit logs record who changed secret metadata, which workspace consumed a reference, and when policy changed without copying raw secrets.
Access surfaces
Every access path has an allowlist and a blocked surface.
Signed dev links are intentionally narrower than authenticated workspace access, and private network access can be enabled without turning every service into a public URL.
Signed dev sessions
Public review stops at the app boundary.
Signed dev links are not a tunnel into the VM. The gateway validates the signed service, workspace, organization, and expiration before it wakes or routes to the app surface.
- Bind
A signed dev link binds one service, workspace, organization, and expiration before gateway traffic can reach the runtime.
- Allow
Reviewers can use the app surface: web, same-origin /api, assets, and WebSockets for that workspace session.
- Block
SSH, secrets, logs, runtime admin, Tailscale private routes, root access, and resource consoles stay outside the signed browser session.
Lifecycle controls
Signed links should be disposable without losing the workspace.
Review access can be granted, rotated, expired, or revoked while the authenticated shell, runtime state, and audit trail remain separate product surfaces.
- Issue
Only an authorized organization member can create a dev link for an assigned workspace service. The link records issuer, service, workspace, organization, and expiration.
- Use
The gateway validates the signed scope before setting the browser session, then rechecks the session on app, same-origin /api, asset, and WebSocket requests.
- Expire or revoke
Expired and revoked links stop at the gateway, even if the runtime is awake. Revocation does not tear down the workspace shell or delete runtime state.
- Audit
Dev link issue, first use, expiration, revocation, and allowlist changes stay visible without logging raw secrets, cookies, or private resource console data.
SurfaceAllowedBlocked
CLI and dashboard
Auth0 organization members with EnvForge product roles
Unknown users, wrong org context, revoked CLI sessions
Signed dev link
Workspace-scoped browser sessions with expiration and service allowlists
SSH, secrets, logs, runtime admin, private consoles
Tailscale private access
Tagged shell/runtime devices joined to the customer tailnet
Public gateway access when the workspace is Tailscale-only
Runtime host
Same-organization workspaces according to placement, root policy, and least-privilege runtime IAM
Cross-customer co-tenancy and broad platform IAM permissions
Runtime and billing
Sleep changes the bill, not the security boundary.
Runtime billing and access control are separate concerns. Sleeping a runtime stops metered service CPU and memory, but it does not expose a dormant workspace, bypass Auth0, widen signed dev link scope, or erase the audit trail.
Authenticated shell access, Git checkout, tmux sessions, logs, and workspace metadata stay available outside the runtime meter.
Dev URL traffic, tests, service commands, or agent jobs wake the organization-owned runtime VM for app, API, worker, database, cache, mail, and storage work.
Auto-sleep stops runtime billing without deleting the workspace or changing who can authenticate to the shell later.
Audit trail
Security work should leave a timeline.
First-release support needs enough event history to explain who opened a workspace, what woke the runtime, which dev link was used, and which policy changed.
- Audit logs record workspace created, shell connected, runtime started, and runtime slept.
- Signed dev link created, used, expired, or revoked.
- Signed dev link allowlist changed for web, same-origin /api, assets, or WebSockets.
- Secret metadata changed without exposing raw values in logs or UI.
- Tailscale device joined, tagged, disconnected, or cleaned up.
- Root policy changed or elevated runtime access requested.
Security reporting
Report security issues with enough context to act.
EnvForge security reports should go to a direct product security channel, include the affected boundary, and avoid copying raw secrets or unrelated customer data into the report.
response pathsecurity inbox
- Acknowledge
- one business day
- Triage
- severity + owner
- Resolve
- fix + customer notice
Name the organization, workspace, signed dev link host, affected service, and whether the report involves shell, runtime, gateway, or dashboard access.
Describe the data or capability at risk, such as cross-organization access, secret exposure, private logs, root elevation, or unsigned dev traffic.
Share timestamps, request IDs, command output, screenshots, and minimal reproduction steps without sending raw secrets or unrelated customer data.