Built for running other people's SQL.

What is built and tested?

• One machine per run. Each run boots a fresh microVM that is deleted when it finishes. Nothing is shared between runs.
• Lockdown before your SQL. Sources are loaded first. Then file access, network access and extension loading are switched off and the settings are frozen. Inside a real microVM, reading a local file, an HTTPS URL or an S3 object, writing a file, attaching a database and trying to undo the lockdown were all refused.
• The writer never sees your SQL. Results leave through one staging directory. A separate connection, which never ran your SQL, writes the sink.
• No secrets in files. A config names an environment variable. A config with an inline password is rejected. The runner passes the value to the connector, not to your SQL.
• No injection through names or values. Table and column names must be plain identifiers, and the watermark is a bound parameter.
• Verified writes. Checks run before the write; the sink is read back after it; state is saved last.

What is planned but not built?

• Network allow-listing for connectors. The platform does not enforce an outbound allow-list on the plan we prototyped on, so connectors can reach the internet before lockdown. We will enforce an allow-list ourselves before opening the beta, and test it.
• A cross-tenant network test across two machines, before any isolation claim is made.
• Invite-only sign-in with GitHub, hashed sessions and scoped tokens; audit log of state changes.

How do I report a problem?

Email security@dpaas.dev. The same address is in /.well-known/security.txt. Please include the steps to reproduce, and allow us time to fix an issue before you publish it.