Security at Swirls
Your systems hold customer data and credentials. This page shows exactly how Swirls protects them, from the attacks we designed for to how every run is recorded, and every claim on it is checkable.
Attacks we considered, and what stops them.
Agents call external APIs, hold secrets, pass data between nodes, and invoke other agents. Each row is an attack on one of those surfaces and the control that prevents it.
Layers of enforcement.
Every agent's authority is derived through five levels. Each level can only add restrictions to the one above it. Taking a restriction back would mean reversing a hash, so the token either verifies against your workflow or it doesn't.
Its own derived keys. One org can't touch another's data.
workspace=acme-corp, expires=<ts>Binds the hash of your compiled workflow. Change it and the token dies.
deployment_id=dep_xyz, workflow_hash=sha256:a1b2c3...One run only. Unique identifier, one-hour expiry, revocable.
execution_id=run_001, [email protected], expires=<+1h>Where a step runs. The token narrows to the node and its declared secrets.
node_id=classify, allowed_secrets=API_KEYOne provider's tokens, one project. A credential minted for one client's project can't redeem another's.
tool_scope=slack, project_id=proj_abcZero stored key material.
Keys are derived the moment they are needed and discarded right after. Nothing is written to the database, so there is nothing there to steal. Each node gets its own encryption context, and rotating a key is an O(1) operation that leaves your data ciphertext untouched.
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.
Search without decrypting
Encrypted records carry a keyed index, so exact-match and substring queries run over ciphertext. Data stays encrypted even while you search it.
A key set per project
Every project gets its own key set the moment it is created. Client separation is cryptographic, not a row filter.
Nothing to audit but the standard library
The crypto core uses platform-native primitives only, with no third-party cryptography dependencies.
Every node only sees what it needs.
The workflow definition declares which secrets each node needs, the token narrows to that node, and the runtime provisions only those secrets into its sandbox. A code node that processes data never sees the API keys the upstream agent uses.
Every change leaves a trail.
Every deploy, token grant, agent authorization, and integration credential lands in an append-only operational log you can export. Key operations get a second, stronger record: each entry carries the hash of the one before it, so changing, deleting, or reordering any entry breaks the chain, and you can verify the chain yourself.
The primitives.
The whole stack is symmetric and hash-based. Here is every primitive we use.
Where we are.
Swirls is a pre-launch platform. This is our compliance posture today, exactly as it stands.
SOC 2 Type II
Targeting 2027. We are building with SOC 2 controls from day one.
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.
We respond within 48 hours.
Send vulnerability reports, security questions, and requests for our security overview document to [email protected].
Start building today.
Start with one task. Build the system around it. Run it for one client, then every client.