Skip to main content
r5d.chat runs AI-generated code on your infrastructure. This page describes what the security model guarantees, and equally importantly what it does not.

​
Trust boundaries

Sessions are cookie-based and signed. Every API handler re-checks that the authenticated user owns the records it touches. The browser never receives a workspace token, and all workspace traffic is proxied through the control plane.
Each workspace has a random 32-byte bearer identity stored in a Kubernetes Secret and mounted into the pod. It maps to exactly one user, is never shown to users or models, and authenticates both directions of the private protocol.
Tenant pods receive no service-account token, host path, runtime socket, or host namespace. automountServiceAccountToken is false and service links are disabled, so a workspace has no ambient Kubernetes credential to use.
Provider keys, custom headers, MCP headers, and OIDC client secrets are AES-256-GCM encrypted with SETTINGS_ENCRYPTION_KEY and stay in the control plane.
Provider, MCP, and OIDC destinations pass a guard that rejects non-HTTPS URLs, credential-bearing URLs, private/loopback/link-local/metadata addresses, and unsafe redirects, unless explicitly relaxed.

​
Workspace pod hardening

Workspace containers run as root on purpose, so agents can install packages for their task. Root is constrained:
Root in an unprivileged container is not a complete sandbox against hostile code. A container escape through a kernel vulnerability remains possible. For mutually untrusted tenants, use a VM boundary such as Kata or gVisor, Pod Security admission, resource quotas, image policy, monitoring, and dedicated node pools.
Enable a VM boundary with:

​
File access boundaries

There are two deliberately different boundaries:
  • UI file APIs are confined to canonical paths under /home/r5d. Path traversal and symlink escapes are rejected, so the file browser cannot be used to read arbitrary container paths.
  • Agent tools intentionally operate anywhere inside the container. The agent’s boundary is the pod itself, because installing and configuring software requires writing outside the home directory.

​
Threats to plan for

Content the agent reads, whether a web page, a document, or an MCP tool description, can contain instructions aimed at the model. Combining broad web access with high-privilege MCP tools increases the blast radius. Give MCP servers narrowly scoped credentials.
Tool definitions are model instructions. r5d.chat fingerprints them on approval and surfaces later drift, but the initial trust decision is yours. See MCP servers.
Agents can run expensive commands. Workspace CPU and memory limits bound a single pod; namespace quotas bound the aggregate. Set both.
A workspace with internet egress can send file contents anywhere. Set networkPolicy.workspaceInternetEgress: false for sensitive tenants, accepting that agents can then no longer install packages.
Before setup is claimed, anyone who reaches the URL can become the administrator. Always set SETUP_CLAIM_TOKEN before exposing an unclaimed installation.
Provider API keys are write-only, but custom headers are returned to the authenticated owner so they remain editable. Treat header values as user-visible secrets.

​
Hardening checklist

1

Set a claim token before exposure

SETUP_CLAIM_TOKEN in the Secret, claimed immediately after go-live.
2

Keep the outbound guard strict

Leave ALLOW_PRIVATE_EGRESS and ALLOW_INSECURE_HTTP at false unless a specific endpoint requires otherwise.
3

Use a VM runtime for untrusted tenants

workspace.runtimeClassName: kata or gvisor.
4

Keep NetworkPolicy enabled

networkPolicy.enabled: true, and decide deliberately about workspaceInternetEgress.
5

Apply namespace quotas

Bound total pods, CPU, memory, and storage so one tenant cannot starve the rest.
6

Use TLS end to end

Terminate HTTPS at the ingress and set publicUrl to the https:// URL.
7

Protect the encryption key

Store SETTINGS_ENCRYPTION_KEY in a secrets manager and back it up with the database.
8

Keep a local admin account

Even with SSO enabled, as an identity-provider outage recovery path.
9

Update images regularly

The workspace image carries a large package surface; rebuild it to pick up security updates.

​
Multi-tenancy guidance

Colleagues under one policy. Default settings are appropriate: standard container isolation, NetworkPolicy on, internet egress enabled.

​
Reporting a vulnerability

Report security issues privately through the repository’s security advisory process rather than a public issue.