Security model

Full machine access

AI Labs is designed as your computer, served to you. Once authenticated, a user has full access to the host filesystem and shell — equivalent to an SSH session. There is no path sandboxing and no per-user isolation.

This is safe when you are the only user and you control the network. It is not safe if:

• untrusted users share the instance,
• it's exposed to the public internet without a trusted gateway in front, or
• a reverse proxy forwards spoofable auth headers (see Authentication).

Treat a shared AI Labs instance like an open SSH port.

What is protected

Even with full access, a few guardrails apply:

Guardrail	Effect
.env protection	.env files are blocked from reading in the UI and the agent's file tools.
Credential-file avoidance	The file-reading tool avoids common credential files (SSH keys, cloud credential stores).
Proxy middleware auth	The in-workspace browser proxy requires a valid session.
GitHub mutation gating	gh operations that write to GitHub are gated by an admin policy / execution identity.
Tool approval	Every tool call can require review before running.
Tamper-evident activity log	A hash-chained record of sign-ins, terminal sessions, config changes, and API mutations, independently verifiable.

Hardening a deployment

• Put AI Labs behind a trusted reverse proxy or a private mesh (Tailscale); don't bind 0.0.0.0 on an untrusted network.
• Use trusted_header auth only when the proxy strips the identity header from inbound requests, and set trusted_sources to the proxy's IP.
• Restrict CPTR_CORS_ALLOWED_ORIGINS when embedding.
• Enable the audit log and, in Docker, continuous backup.
• Keep tool approval in review (not blanket Auto) for shared or internet-facing instances.

License

Open Use License. Source available. Commercial licenses and enterprise licenses are available.