YOUR SECURITY IS STRUCTURAL.
Swirls was built for workloads that touch sensitive data. The security model is the platform's 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 workflow definition it's running, chained through five delegation levels with HMAC. The code and the policy are the same artifact.
WHAT WE'RE DEFENDING AGAINST.
AI agents can access 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.
FIVE LEVELS. ONE DIRECTION.
Permissions flow through a five-level delegation chain using cryptographic tokens. Each level appends restrictions by chaining HMAC-SHA256 on the existing signature. Removing a restriction would require inverting the hash. Computationally infeasible.
The token either verifies against the workflow hash, or it does not.
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.
EVERY NODE GETS ONLY 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.
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.
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.