Security

Built to be trusted with your keys

The platform holds two sensitive things: your project content and the credentials that let it act on your accounts. Our approach: minimize what we hold, encrypt what we must hold, isolate everything that executes, and record everything that matters.

AES-256-GCM
Row Level Security
Sandboxed builds
Command allowlists
Signed webhooks
Audit logs

Encryption at rest & secret masking

Every credential you connect — OAuth tokens, API keys (including bring-your-own OpenAI and Anthropic keys), and environment variables destined for your deployed products — is encrypted at rest with AES-256-GCM authenticated encryption. Each value gets a fresh random nonce, and the authentication tag guarantees tampering is detected.

Once you save a secret, its full value is never displayed again. Interfaces show at most the first and last four characters (like sk-a••••6789), and build logs and error output pass through a redaction layer that strips anything shaped like a credential — API keys, GitHub and Render tokens, JWTs, connection strings, and private key blocks.

Row Level Security

The platform database enforces Postgres Row Level Security on every customer-facing table. Access policies scope reads and writes to the authenticated user, so tenant isolation is enforced by the database itself — not just by application code. There is no code path that reads another customer's projects, builds, or secrets.

Isolated build sandboxes

AI-generated code is never executed on our application servers. Every build step runs inside a disposable container created for that build and destroyed afterward, with strict guardrails:

  • CPU and memory limits (1 CPU and 2 GB by default) plus a process cap
  • A hard timeout on every step — 15 minutes by default
  • Restricted network egress, limited to what a build legitimately needs
  • A command allowlist: only known-safe commands (dependency install, build, lint, type check, tests) are accepted; everything else is rejected and logged
  • Shell metacharacters are rejected outright — no command chaining, substitution, or redirection
  • Automatic cleanup: the container and its workspace are removed when the step finishes

Prompt-injection defenses

Content that enters the pipeline from outside — your project descriptions, attached references, third-party pages, and even the AI's own generated output — is treated as untrusted data, never as instructions to the platform. Untrusted text cannot change what the pipeline is allowed to do.

Because every executed command must match the allowlist and every sandbox is isolated and network-restricted, a prompt-injection attempt that steers the model toward running unexpected commands hits a hard wall: the command is rejected, the attempt is logged, and the blast radius stays inside a disposable container.

Webhook signature verification

Inbound webhooks from GitHub, Render, billing, and email providers are verified with HMAC-SHA256 signatures before any processing occurs, using constant-time comparison to prevent timing attacks. Requests with missing or invalid signatures are rejected and recorded.

Audit logging

Security-relevant events — sign-ins, credential connections and disconnections, build launches, deployment actions, and administrative access — are written to append-only audit logs with timestamps and actor identifiers. Logs are retained for a bounded operational window and support investigation of suspected account compromise.

Ownership & export

The best data protection is not holding your data hostage. Your code lives in your GitHub repository from the first commit, your deployment runs in your Render workspace, and your database is in your own account. You can additionally export your blueprint, schema, and configuration at any time — and revoking the platform's access never takes your product down.

Responsible disclosure

We welcome good-faith security research. If you believe you have found a vulnerability, contact us with a description and reproduction steps. We acknowledge reports promptly — typically within two business days — keep you informed of remediation, and do not pursue legal action against research conducted in good faith. Please do not access other users' data or publicly disclose an issue before we have had a reasonable opportunity to fix it.