Security Model & Isolation

Security is the core feature of Dwizi. We execute untrusted code so you don't have to worry about it. This document outlines our Threat Model and the security controls we enforce.

Threat Model

We design our system assuming the code we run could be malicious. Our threat model focuses on protecting the platform and other tenants from hostile actors.

Key Threats

Container escape: An attacker tries to break out of the runtime environment to access the host or other containers.
Data exfiltration: A malicious tool attempts to access data or secrets belonging to other users or organizations.
Abuse: Excessive compute usage or Denial of Service (DoS) attacks via public tool URLs.
Credential theft: Attempts to hijack sessions or leak access tokens.
Supply-chain risk: Malicious dependency injection in the build pipeline.

Security Controls

Isolation and Runtime Hardening

Every tool execution occurs within a hardened container environment.

Sandboxed Execution: Tools run in isolated containers with limited privileges and resources.
Non-Root Execution: Containers run as a non-privileged user to limit the blast radius of any potential exploit.
Ephemeral: The container is created for the run (or a warm pool) and destroyed or reset.
Resource Limits: Strict CPU and memory limits are enforced per container to prevent noisy neighbor issues.
Filesystem: The filesystem is largely read-only or ephemeral; files written to disk are lost when the run ends.

Access Control & Authentication

You control who can execute your code.

Authentication: We use magic-link authentication via Resend for secure user sessions without password risks.
Organization Isolation: Strict multi-tenant data isolation is enforced via org_id scoping in the database and API.
Role-Based Access Control (RBAC):
- Owners/Admins: Can modify tool code and settings.
- Members: Can execute tools but cannot modify code.
- Viewers: Can only inspect logs and results when retention is enabled.

Public vs. Private Tools

Private Tools (Default): Require a valid Authorization header. Only organization members can invoke them.
Public Tools: No authentication required. Anyone with the URL can run it. Use with caution and avoid exposing sensitive secrets.

Data Security

Secrets Management: Environment variables (Env) are encrypted at rest. They are injected into the container only at runtime and are never exposed in the browser client or logs.
Retention Controls: By default, Dwizi retains audit events only. Output/log retention is configurable and can be disabled for compliance-sensitive workloads. See Data Retention.
Secure Headers: The gateway implements standard security headers (HSTS, X-Content-Type-Options, etc.) to protect clients.
Input Validation: We enforce file size limits and validate entry points to prevent malformed payloads.

Abuse Prevention

Rate Limits: We enforce rate limits per user, team, and tool to prevent abuse.
Auto-shutdown: Idle containers are automatically shut down to free up resources.
Quotas: Runtime minutes and storage are quota-managed.

Security Checklist

We continuously monitor and improve our security posture.