Secure by Default

Spade takes security seriously. In the cloud, every block executes inside a sandbox that limits what it can access.

Process Isolation

In cloud execution, each block runs as an independent subprocess inside an isolate sandbox. This provides:

• Filesystem containment — Blocks can only access their invocation working directory
• Process isolation — Blocks cannot interfere with each other or the host system
• Resource limits — Memory and CPU usage are constrained per block

isolate is Linux-only. Running spade run locally on macOS or Windows executes blocks as plain subprocesses under your own user account, without this sandboxing — the same trust model as running any other CLI tool you've installed.

Network Access

Network access is disabled by default. Blocks that need network connectivity must explicitly declare it in their manifest:

network: true

This opt-in model ensures that data processing blocks can't make unexpected network calls unless authorized.

Integrity Verification

Spade computes a content hash of each block at install time. Before execution, the worker verifies the hash to detect any post-install tampering. If the hash doesn't match, execution is halted.

Trust Model

• Collections published to the cloud registry are screened, then built, then cryptographically signed — in that order, so the registry controls what gets signed
• Every installed block is content-hashed locally to detect post-install tampering, regardless of where it came from
• In the cloud, the sandbox prevents untrusted code from escaping its boundaries
• Network declarations are visible in the manifest for audit
• All block execution is logged for traceability