Security Architecture

1. Compute Isolation Architecture

Every AI-generated application is built and executed in an isolated E2B cloud sandbox.

• Each active project runs in a separate sandbox with its own filesystem and process space.
• AI tools execute inside the project sandbox rather than on the Clawder application server.
• Disconnected sandboxes can be paused and resumed so project files remain available.
• Deleting a project destroys its sandbox. Marketplace releases are archived separately in private object storage.

2. Identity and Access Management

Robust identity verification and granular access controls protect user workspaces and account data.

• Authentication: Supabase Auth provides password and OAuth authentication with signed, expiring sessions.
• Session Management: Protected API and WebSocket operations validate the current access token before granting access.
• Data Isolation: Row-level security and server-side ownership checks restrict projects, messages, purchases, and payout data.
• Admin Access: Administrative functions require explicit role assignment. Demo admin accounts are automatically restricted to read-only operations.
• Service Credentials: Platform API keys stay in server environment variables. User integration tokens are only sent to authenticated server endpoints and are not stored in browser storage.

3. Cryptographic Standards

Production deployments rely on HTTPS and the encryption controls supplied by the configured infrastructure providers.

• In Transit: Configure the public application and WebSocket endpoints behind HTTPS in production.
• At Rest: Supabase and the selected hosting providers manage database and object-storage encryption.
• Sensitive Data: Secret keys belong in server-side environment variables and must never be committed to source control.

4. Runtime Security and Threat Mitigation

Automated agents operate within strict operational boundaries to prevent unauthorized actions or platform abuse.

• Execution is restricted to user-space operations within the isolated compute instance.
• Billing and administrative operations execute outside the project sandbox and require authenticated server-side authorization.
• Compute limits and concurrent sandbox capacity follow the operator's E2B account configuration.
• Sandboxed applications may make outbound requests, so operators should add network restrictions when their deployment requires them.

5. Infrastructure Security

The underlying infrastructure is designed with defense-in-depth principles.

• Supabase, E2B, and the selected web host provide the underlying managed infrastructure.
• Marketplace archives are stored in a private Supabase Storage bucket and delivered only after authorization.
• Operators control backups, retention, firewall, DDoS, and regional settings through their provider accounts.
• Dependencies and the deployment environment should be patched and reviewed as part of normal operations.

6. API Security

All API endpoints are protected with multiple layers of security.

• Usage Enforcement: Agent work is checked against user credit limits. Operators should also configure edge rate limiting for public endpoints.
• Input Validation: Sensitive marketplace, billing, deployment, and admin operations validate input server-side.
• Authorization: State-changing APIs require bearer-token authentication and verify ownership or administrative roles.
• Admin Endpoints: Administrative API routes verify role-based access on every request. Write operations are blocked for demo accounts at the server level.

7. Marketplace Security

The integrated marketplace includes specific protections for buyers and sellers.

• Payment Processing: All marketplace transactions are handled by Stripe. We never store credit card numbers on our servers.
• Download Delivery: Published app archives are stored in a private storage bucket. Downloads require an authenticated account with a completed purchase, and remain available when the seller's sandbox is removed.
• Seller Data: Sellers cannot access buyer email addresses, payment details, or personal information. Only the platform administrator can view transaction details.
• Payment Reconciliation: Signed Stripe webhooks are deduplicated, and refunds and disputes reverse seller earnings in the marketplace ledger.

8. Monitoring and Incident Response

Clawder records application, database, and payment events through its configured services.

• Stripe webhook outcomes are retained for replay protection and payment troubleshooting.
• Supabase, hosting, and E2B logs can be connected to the operator's preferred monitoring and alerting tools.
• Operators are responsible for defining incident-response contacts, retention, escalation, and legally required notifications.

9. Vulnerability Disclosure

We welcome responsible disclosure of security vulnerabilities.

• If you discover a security vulnerability, please report it to [email protected] with a detailed description and reproduction steps.
• We commit to acknowledging receipt within 48 hours and providing a resolution timeline within 7 days.
• We do not pursue legal action against researchers who report vulnerabilities in good faith and do not access or modify data beyond what is necessary to demonstrate the issue.

10. Compliance

The platform is designed with compliance considerations in mind.

• GDPR: The platform includes access controls and data-management foundations that can support a compliant deployment. The operator remains responsible for configuration, policies, and legal obligations.
• Data Processing: Subprocessors (AI providers, cloud infrastructure, payment processors) are selected based on their security certifications and data handling practices.
• Auditability: Payment webhook events and provider logs support operational investigation; operators can add longer-term audit retention as required.

11. Contact

For security-related inquiries, vulnerability reports, or data protection questions, contact us at [email protected].