Security Overview

1. Our Approach

Idea to Life handles two kinds of sensitive material: your project content and the credentials that let us act on your accounts. Our security program is built around minimizing what we hold, encrypting what we must hold, isolating everything that executes, and recording everything that matters. This overview summarizes the main technical controls; it is descriptive, not a contractual guarantee, and we improve these controls continuously.

2. Encryption

All traffic between your browser and the platform, and between the platform and third-party APIs, is encrypted in transit with TLS. Secrets at rest — connected OAuth tokens, API keys (including bring-your-own OpenAI and Anthropic keys), and environment variables destined for your deployed applications — are encrypted with AES-256-GCM authenticated encryption. Encryption keys are stored separately from the encrypted data, access to them is restricted, and keys can be rotated without customer disruption. Database storage and backups are additionally encrypted at the infrastructure layer by our hosting providers.

3. Data Isolation with 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 rather than relying solely on application code. Service-level operations that must cross tenants run through narrowly scoped, audited paths.

4. Isolated Build Sandboxes

Every build runs in an isolated, ephemeral sandbox that is created for the build and destroyed afterward. Sandboxes have no access to other customers' builds or data, run with constrained CPU, memory, and time budgets, and have restricted network egress limited to the endpoints a build legitimately needs (package registries, your connected providers, and AI APIs through our gateway).

5. Command Allowlists

Automation inside the build pipeline does not get a free shell. Commands executed during generation, testing, and deployment are checked against explicit allowlists; anything outside the allowlist is rejected and logged. This limits the blast radius of both model mistakes and prompt-injection attempts that try to steer the pipeline into running unexpected commands.

6. Webhook Signature Verification

Inbound webhooks — from GitHub, Render, our payment processor, and other integrations — are verified against their provider signatures (HMAC or equivalent) before any processing occurs. Requests with missing or invalid signatures are rejected and recorded. Outbound webhook-style callbacks we emit are signed so receiving systems can verify us in turn.

7. Secret Masking and Redaction

Secrets are decrypted only at the moment of use and are systematically masked elsewhere: build logs, error reports, and user interfaces redact known secret values and token-shaped strings; secrets are excluded from prompts sent to AI models except where an integration explicitly requires a designated value; and full secret values are never displayed back after you save them. If a secret is suspected to have leaked, we support immediate rotation by disconnecting and reconnecting the integration.

8. Audit Logging

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

9. Operational Practices

Access to production systems is limited to a small number of operators using strong authentication, granted on a least-privilege basis, and reviewed periodically. Dependencies are monitored for known vulnerabilities, and patches for critical issues are prioritized. We maintain an incident response process that includes containment, customer notification where legally required or otherwise warranted, and post-incident review.

10. Responsible Disclosure

We welcome good-faith security research. If you believe you have found a vulnerability, report it to the security contact address listed in the application footer with a description, reproduction steps, and any relevant identifiers. Please do not access other users' data, degrade the Service, or publicly disclose the issue before we have had a reasonable opportunity to fix it. We commit to acknowledging reports promptly (typically within two business days), keeping you informed of remediation progress, and not pursuing legal action against research conducted in good faith within these guidelines. Testing must not target the third-party providers we integrate with except under their own disclosure programs.