Security

Last updated: June 17, 2026

Chatspaces runs your code and holds credentials for your accounts, so security is core to the product. This page explains how we isolate workloads, protect credentials, and handle data — and how to report a vulnerability. It describes our practices as of the date above; security is ongoing work, and we update this page as the product evolves.

1. Sprite isolation

Each chatspace runs on its own isolated cloud machine — a "sprite" — bound to your repository and branch. A sprite is single-tenant: it belongs to one chatspace and is not shared with other users. It is dormant between sessions and booted on resume, and it is destroyed when you delete the chatspace.

Within a sprite, the code that you and the agent run executes as an unprivileged, non-root user, separated from the control components by Linux user, mount, and capability boundaries. That separation is designed so that the workload cannot drive the underlying platform control plane, cannot capture raw network traffic, and cannot read our orchestration code or platform secrets. Workloads run without elevated privileges (no sudo, no ambient capabilities, no_new_privs set), and resource usage is accounted per chatspace.

2. Encryption

• In transit. Connections to the app, our API, and sprite preview URLs are served over HTTPS/TLS. We send HSTS and other hardening headers on our web surfaces.
• At rest. Data stored in our database is encrypted at rest by our infrastructure providers.
• Credentials. Provider credentials and environment secrets receive an additional layer of application-layer envelope encryption before they are written to the database — each is encrypted with a per-user data key (AES-256-GCM), which is itself wrapped by a key-encryption key that lives outside the database. This is designed so that a leak of the database alone yields inert, wrapped ciphertext.

3. Credential handling

To run agents for you, we hold a GitHub authorization and — only with your explicit consent — your Claude or Codex sign-in. We handle these with care:

• Saved only with consent, and revocable at any time. Deleting your account revokes and deletes them and tears down your sprites.
• Envelope-encrypted at the application layer (see above), with database row-level security denying direct access.
• Least exposure on the machine. The platform credentials we use to provision sprites are never sent to a sprite. GitHub access for cloning and pushing is brokered through short-lived, repository-scoped tokens rather than handing your long-lived token to the workload.
• No secrets in logs. Our logging redacts credential-shaped values, and we test against regressions that would log them in plaintext.

One honest note about any agentic coding tool: while a chatspace is running, the agent and the session need access to your own credentials on the machine to do their work — just as the same tools would on your laptop. Because each sprite is single-tenant, the blast radius of that access is your own account, and we minimize it with scoping, short lifetimes, and isolation.

4. Access & auditing

Access to credentials runs through narrow, server-side functions, and every read, write, and revocation of a provider credential is recorded in an audit log (who accessed it, through which endpoint, and why). Internal access to production systems is limited to the people who need it. We monitor for anomalies and aim to investigate and respond to incidents quickly.

5. Data & residency

Your source code lives in your GitHub repositories and on the sprite provisioned for your chatspace; we do not keep a separate mirror of your repository contents, and a sprite's working tree is destroyed when the chatspace is deleted. The AI conversation itself runs in the provider's product under your own account. Our database and compute are hosted in the United States. For the full picture of what we collect and how long we keep it, see our Privacy Policy.

6. Sub-processors

We rely on the following providers to deliver the Service. Each is bound to protect your data consistent with our Privacy Policy, and we aim to give notice of material changes to this list.

7. Shared responsibility

Security is a partnership. Here is the split:

8. Reporting a vulnerability

We welcome reports from security researchers and will work with you to fix issues responsibly.

How to report. Email security@chatspaces.dev with enough detail to reproduce the issue (steps, affected URL/endpoint, and impact). We aim to acknowledge reports within 3 business days and to keep you updated through triage and resolution.

Scope. In scope: chatspaces.dev and our API, and the Chatspaces mobile app. Out of scope: our sub-processors' own infrastructure, denial-of-service or volumetric testing, social engineering, physical attacks, and any testing that accesses or disrupts another user's account, data, or sprite.

Safe harbor. If you make a good-faith effort to comply with this policy during your research, we will consider it authorized, will work with you to understand and resolve the issue promptly, and will not pursue or support legal action against you. Please give us a reasonable opportunity to fix an issue before disclosing it publicly, avoid privacy violations and service disruption, and only interact with accounts you own or have permission to test.

A machine-readable contact is published at /.well-known/security.txt.