Security that is structural.
Swirls was built for workloads that touch sensitive data. The security model is the execution model. We name the algorithms and describe the construction so you can evaluate them.
Every agent's permissions are derived from the SHA-256 hash of the exact .swirls definition it's running. A macaroon-style chain attenuates that root through five levels with HMAC. Identity is federated at the edge with OIDC. Tools are themselves scoped graphs. The code and the policy are the same artifact.
Security at a glance
Five authorization levels. Workspace > Deployment > Execution > Node > Tool.
Zero stored keys. Key material derived per-operation via HKDF-SHA512. Nothing stored.
Tamper-evident everything. Audit logs chained with SHA-512 hashes. Tamper breaks the chain.
What we're defending against.
AI agents reach external APIs, secrets, intermediate data, and other agents. A compromised agent, a stolen token, a tampered audit log. We designed for these scenarios before building the platform.
Compromised agent escalates tool access
The agent receives an HMAC-chained token scoping it to specific tools. Calling an unauthorized tool requires inverting HMAC-SHA256, which is computationally infeasible.
Cross-tenant data access
Per-tenant HKDF key derivation ensures keys from one workspace cannot decrypt data from another. Encryption contexts bind tenant identity as authenticated additional data (AAD) at both encryption layers.
Node reads another node's intermediate state
Each node's output is encrypted with a node-specific encryption context. The execution engine decrypts and re-encrypts at each edge. Nodes never see raw ciphertext from other nodes.
Replay of a previous execution's token
Each execution token includes a CSPRNG nonce and a short-lived expiry. The nonce is checked against a revocation set. Time-bound caveats expire tokens within the execution window.
Prompt injection manipulates agent behavior
Cryptographic authorization tokens constrain what tools and secrets an injected agent can reach, limiting blast radius. Swirls also supports sandboxed tool execution, structured outputs, and human-in-the-loop gates for high-consequence actions. Prompt injection within authorized scope remains an industry-wide challenge. We scope permissions tightly and add defense in depth rather than claiming the problem is solved.
Supply chain compromise in runtime dependencies
Workflow execution runs in isolated containers with pinned dependencies. The compiled workflow hash ensures the exact definition that was reviewed is the one that runs. Runtime dependencies are audited and vendored where possible.
Insider access to customer workflow data
All intermediate state is encrypted with per-node keys derived from customer-scoped root secrets. Swirls employees do not have access to plaintext workflow data. Infrastructure access requires multi-party approval and is logged in the audit chain.
Stolen federated identity token
OIDC tokens minted at run time are scoped to the requesting workflow hash and short-lived (typically minutes, never persisted to disk). A stolen token cannot be replayed against a different .swirls definition because the workflow hash is bound as a caveat. There are no long-lived provider credentials sitting in env vars to steal.
An agent invokes an unsafe tool
Tools are graphs. When an agent calls another graph as a tool, the called graph runs under its own scoped delegation chain, with its own declared secrets and OIDC federations. There is no path for an agent to escape its declared tool surface, because the tool is itself a workflow definition the runtime compiled and verified.
Five levels. One direction.
Permissions flow through a macaroon-style five-level delegation chain. Each level appends restrictions by chaining HMAC-SHA256 on the existing signature. Removing a restriction would require inverting the hash. Computationally infeasible.
At the edge, OIDC federations mint provider-scoped tokens bound to the same workflow hash. Inside the chain, graphs invoked as tools enter a sub-chain that inherits the caller's caveats and adds its own.
The token either verifies against the workflow hash, or it doesn't.
Tenant-level root token. HKDF key derivation ensures cryptographic isolation between organizations. Keys derived under one workspace cannot decrypt data from another, regardless of access control state.
workspace=acme-corp, expires=<ts>Attenuated from workspace. The SHA-256 hash of the compiled .swirls definition is embedded as a caveat. Any modification to the workflow produces a different hash and invalidates the token.
deployment_id=dep_xyz, graph_hash=sha256:a1b2c3...Attenuated from deployment. Scoped to a single workflow run with a CSPRNG nonce for replay prevention. Short-lived TTL ensures tokens cannot be reused across executions.
execution_id=run_001, nonce=<csprng>, expires=<+1h>Attenuated from execution. Each node in the DAG receives a token scoped to its specific type, tools, and secrets. An LLM node cannot access tools or secrets not declared in the workflow definition.
node_id=classify, allowed_tools=search, allowed_secrets=API_KEYAttenuated from node. The most restricted token in the chain. Scoped to a single tool invocation with endpoint and resource constraints.
tool_id=search, allowed_endpoints=api.example.comZero stored key material.
Key material is derived deterministically from a root secret and a random salt using HKDF-SHA512. Given the same inputs, any server instance produces identical key material. The server derives on demand and immediately discards. There is nothing to steal from the database layer, because key material is never written to it.
Each node in a workflow gets its own encryption context. Data encrypted by node A cannot be decrypted by node B, even within the same execution. The execution engine acts as the cryptographic intermediary, decrypting outputs from one node and re-encrypting for the next.
Key rotation is built into the envelope encryption design. Rotating the key encryption key is an O(1) operation that does not require re-encrypting data. Execution tokens are short-lived with CSPRNG nonces. In the event of a root key compromise, all derived keys can be rotated and all outstanding tokens invalidated.
Derived, not stored
HKDF-SHA512 produces key material on demand. Zeroed from memory after use.
Envelope encryption
Two-layer AES-256-GCM. Rotating the key encryption key is O(1). Data ciphertext is unchanged.
Stateless scaling
Any server instance derives the same keys. No synchronization, no shared state, no single point of failure.
Every node only sees what it needs.
Swirls derives the minimum set of secrets authorized by each node's token. The workflow definition declares which secrets each node needs. The runtime enforces it cryptographically. A code node that processes data never sees the API keys used by the LLM node upstream.
Tamper-evident by construction.
Every key derivation, every decryption, every tool invocation is recorded in a cryptographic hash chain. Each entry includes the SHA-512 hash of the previous entry. Modifying, deleting, or reordering any entry breaks the chain.
Audit logs are written to append-only, immutable storage. The signing key for audit entries is separated from operational key material. Customers can export their audit logs for independent verification.
Append-only
Written to immutable storage. Each entry references the previous hash. Insertion or deletion breaks the chain.
Non-repudiable
Every request is logged with the authenticated client ID. Access cannot be denied after the fact.
Continuously verified
Automated verification runs on a schedule. Customers can independently verify their audit chain at any time.
The primitives.
The entire cryptographic stack is symmetric and hash-based. Below are the specific primitives used throughout the platform.
Where we are.
Swirls is a pre-launch platform. We are transparent about our current compliance posture rather than making claims we cannot back up.
SOC 2 Type II
Targeting 2027. We are building with SOC 2 controls from day one rather than retrofitting after the fact.
Data residency
Workflow data is encrypted and stored in the region you deploy to. Self-hosted deployments give you full control over data location.
Subprocessors
Swirls connects to LLM providers you configure. We do not send workflow data to any third party beyond the providers specified in your workflow definition.
Data retention
Encrypted workflow data and derived key material is deleted within 30 days of account termination. See our Privacy Policy for the full retention schedule.
Security contact.
For security inquiries, vulnerability reports, or to request our security overview document, contact us at [email protected]. We respond to security reports within 48 hours.
Five minutes from install to an agent you'd ship.
Install the CLI. Write .swirls files. Run them locally with the same engine that runs in production. When you're ready, git push or swirls cloud deploy. No CI/CD to build.
Building something with Swirls? Come hang out in Discord.
Join the Discord