YOLO Studio was built from day one around the principle that your source code, credentials, and intellectual property deserve uncompromising protection. Every layer of the platform — from container isolation to credential delivery to network policy — is designed to keep your data safe.
Hardware-Isolated Workspaces
Every workspace runs inside its own Kata Container — a Kubernetes pod whose primary container boots its own guest kernel inside a small VM. Kernel-level isolation between workspaces is enforced by hardware virtualization. Session containers are destroyed on session expiry; workspace state (your repo and saved files) lives on a per-workspace persistent volume that is never shared with another workspace or another user.
Isolated Credential Custody
When you sign in with a Claude or ChatGPT subscription, the long-lived sign-in credential is held by a dedicated credential service for your account, with no shell or inbound access, and never enters a workspace. Workspaces receive only short-lived access tokens, delivered per session and never shared with other sessions or users. API keys and secrets you save are encrypted at rest with Google Cloud KMS, and credentials are never written to logs.
Hardened Container Runtime
Containers run as non-root (UID 1000) with all Linux capabilities dropped, read-only root filesystems where possible, seccomp profiles enforced, and privilege escalation explicitly blocked. Cloud metadata endpoints (169.254.x.x) are firewalled to prevent SSRF attacks.
Network Isolation by Default
Default-deny Kubernetes NetworkPolicies restrict all pod-to-pod traffic. Ingress is only allowed from the authenticated platform proxy. Egress is constrained at the network-policy layer: agents can reach the public internet over HTTPS/HTTP/SSH (to fetch packages, push to GitHub, and call LLM APIs), but the entire RFC-1918 address space is blocked — containers cannot reach other customer pods or cluster-internal services.
Encrypted at Rest & in Transit
Managed volumes are encrypted at rest with AES-256, and all data in transit moves over TLS. Database connections to MongoDB Atlas authenticate over TLS with SCRAM-SHA-256, and secrets in the data path are managed through Kubernetes Secrets rather than plaintext environment variables.
Infrastructure
Hosted on Google Kubernetes Engine (GKE) in SOC 2 Type II certified data centers
Container images built in CI and pushed to a private Google Artifact Registry — never pulled from public sources at runtime
Secrets managed through Kubernetes Secrets with RBAC-scoped access — no environment variable leakage across namespaces
Control-plane services (API, auth, LLM gateway, work dispatcher) deploy via rolling updates with pod disruption budgets
WebSocket connections routed through an authenticated gateway proxy — pods are never directly addressable from the internet
Session jobs are namespaced and labeled per-session — cross-tenant network paths are blocked by the default-deny NetworkPolicy
Authentication & Access Control
OAuth 2.0 via GitHub with short-lived JWT tokens — no passwords stored on the platform
All API endpoints protected by bearer token validation through a dedicated auth service
Service-to-service calls use RS256 service JWTs minted by the auth service. Within a workspace machine, loopback requests use a per-pod random shared secret (POD_INTERNAL_KEY); the Kubernetes gateway edge uses its dedicated K8S_PROXY_API_KEY
Session tokens auto-rotate and expire — no long-lived credentials exist in the platform
Rate limiting and abuse detection on all public-facing endpoints
Admin operations require separate elevated authentication — no shared superuser accounts
Agent Execution Security
Each AI agent runs inside the same sandboxed container as the user session — never on shared infrastructure with access to other workloads
Agents operate with the same filesystem and network restrictions as the user — no elevated privileges, no escape hatches
Critic Steps (type-checking, tests, linting) gate every patch at the integration-merge point — agent code lands in its own isolated lane first, and only passing patches advance onto the integration branch
Lane isolation ensures parallel agents work on separate git branches — merge conflicts are surfaced and resolved, never silently overwritten
Context injection is scoped: agents receive their assigned task, role-template instructions, recent commit diffs, and the shared workspace plan — nothing else
Agent credentials (Claude, Codex, etc.) are delivered per-session and never shared across workspaces or users
Automated Security Audit
A dedicated security agent that continuously reviews code changes across your workspace for vulnerabilities, secrets leakage, dependency risks, and policy violations — before anything ships. Every commit is scanned, every PR is audited, and findings are surfaced in real time alongside your development workflow.
Responsible Disclosure
Found a security issue? We take every report seriously. Please reach out to us directly and we will respond promptly.
security@yololabs.ai