Security
How Solaris AI Flow protects your wallet, keys, and credentials.
Solaris AI Flow runs workflows that move funds and call paid APIs on your behalf, often while your browser is closed. That makes key handling the core of the product, not an afterthought. We separate every secret by what it can do, and protect each one accordingly.
Two kinds of secrets
Wallet keys, which control your funds
Your embedded wallet is created by Privy on sign-up. Solaris AI Flow never stores or has access to your private key. Privy uses a defense-in-depth design with hardware-isolated Trusted Execution Environments (TEEs) and distributed key sharding, so the key is never held in one place and is only reconstructed inside secure encrypted environments.
The practical consequence: even a full compromise of Solaris AI Flow infrastructure cannot drain your wallet, because the key that signs transactions is not ours to leak. A workflow can only initiate the on-chain actions it is built to perform, and payments you confirm.
Integration API keys, which call external services
When you connect a credential (an OpenRouter key, a Helius key, a Telegram bot token, a Discord webhook, and so on), the values are encrypted with AES-256-GCM before they are written to the database. Each record uses its own random initialization vector and an authentication tag, so stored values cannot be read or tampered with offline.
- Credential encryption is protected by Google Cloud KMS.
- In the Connections page, stored values are masked.
- Credentials are per-account and are never included in workflow exports or marketplace clones. Buyers of a workflow supply their own keys.
See Credentials for the full list of supported platforms and Adding Credentials for where to get each key.
How a credential is used during a run
- The execution engine loads your encrypted credential records for the workflow being run.
- When a workflow needs a credential, the runtime uses Google Cloud KMS-backed key protection to decrypt it.
- The plaintext key exists only in runtime memory, is attached to the outbound request to the external service (for example, an
Authorizationheader), and is never logged. - When the node finishes, the plaintext is discarded from the execution context. Only the encrypted credential record remains at rest.
How we compare
We use the same battle-tested encryption model as the leading automation platforms, then add Google Cloud KMS protection to our credential encryption architecture. Solaris AI Flow is also web3-native, so wallet custody is separated from integration API-key storage.
| Capability | Solaris AI | n8n | Make |
|---|---|---|---|
| AES-256 encryption at rest | Yes | Yes | Yes |
| Credentials decrypted only at execution time | Yes | Yes | Yes |
| Secrets never exposed to the browser | Yes | Yes | Yes |
| Managed key service / external secrets support | Yes (GCP Cloud KMS) | Enterprise (external secrets) | AWS KMS (full-disk) |
| Non-exportable KMS key | Yes | Depends on deployment | Full-disk |
| Non-custodial: the key that moves funds is never stored | Yes | N/A | N/A |
| Wallet keys reconstructed only inside hardware-isolated TEEs | Yes (via Privy) | N/A | N/A |
| Embedded wallet, no browser extension required | Yes | N/A | N/A |
n8n supports external secret stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) on its Enterprise plan, while its default self-hosted encryption key is local or environment-configured. Make's security page documents AES-256 with AWS Key Management Service for full-disk encryption of data at rest; this is transparent, infrastructure-level encryption (disk-theft scope), and the documentation does not state that stored connection credentials are encrypted with AWS KMS at the application level, so it does not mitigate a database leak the way per-credential encryption does. (Make separately offers an in-workflow AWS KMS app, which is unrelated.) n8n and Make are general-purpose automation platforms, not web3-native, so the wallet and custody rows do not apply to them. Comparison reflects the published security documentation of each platform as of June 2026.
What this design protects against
- Database leak: stored credentials are protected by Google Cloud KMS, so leaked rows are not usable on their own.
- Workflow sharing and resale: exports and marketplace clones carry the workflow logic, never your keys.
- Client-side exposure: secrets are not shipped to the browser, so they cannot be read from network traffic or local storage.
- Infrastructure compromise: the one secret that can move money, your wallet key, is not on our infrastructure to begin with.
What you can do on your side
- Scope each API key to the minimum permissions the node needs.
- Rotate a key in the Connections page if you suspect exposure. Every workflow using that credential picks up the change at once.
- Use a separate key per environment where the provider supports it, so you can revoke one without affecting the others.