Trust

How your data is protected

Specifics rather than adjectives. Everything below is a control that exists in the product today — and the last section lists what we have not done, because a security page that only lists strengths is not worth reading.

Last reviewed 29 July 2026

Credentials are sealed with a key we cannot reproduce

Connector secrets — mail passwords, API keys, phone credentials — are encrypted with a key derived from your master password. That password is never written to our database: the key is derived for a single operation and discarded.

The consequence is deliberate and worth stating plainly: if you lose it, we cannot recover those secrets for you. We would rather be unable to help than be able to decrypt your credentials on demand.

Tenant isolation, in three independent layers

Every table holding customer data carries all three, so no single mistake exposes anything:

  • Grants revoked. The public API roles hold no privileges on those tables at all — not even read.
  • An explicit deny policy. Row-level security states the intent rather than relying on the absence of a rule.
  • Forced row-level security. Applied even to the table owner, so a misconfigured connection still cannot read across tenants.

Authorization fails closed: a request whose credential cannot be verified is rejected, never allowed through on the assumption that a missing check means permission.

Consequential actions are gated

Spending money, sending a message, placing a call or booking travel sits behind an explicit authorization step — a master password for secret-touching actions, and a spoken PIN on the phone line. The gate is enforced at a single chokepoint every channel passes through, so a new channel cannot accidentally bypass it.

A failed action fails loudly. The assistant will never report success for something that did not happen.

An audit trail that cannot be quietly edited

Every action records who did it, what happened, when, and the real outcome — including failures and refusals. Audit records are append-only by design, which is what lets a disputed automated action be reconstructed rather than argued about.

Payments: nothing to steal

  • We accept crypto only, so no card or bank details are collected — and therefore none can be leaked.
  • We never take custody of funds. Payments move from your own wallet to the provider directly.
  • The wallet is owned by you and controlled by your password. We operate it within limits you set, and can watch but not spend beyond them.

The public surfaces are deliberately narrow

The embeddable chat widget is the only anonymous entry point, and it is walled off from the operator tooling: it cannot reach the agent brain, which has internet access and backend tools. Authenticated and transactional routes are excluded from search indexing.

What we have NOT done

Stated plainly so you can weigh it:

  • We hold no SOC 2, ISO 27001, HIPAA or PCI certification. We do not process card data, which is why PCI does not arise.
  • We have not had an independent third-party penetration test.
  • We do not currently offer a formal SLA with financial credits.
  • Data may be processed in the United States by our subprocessors.

If your procurement process needs any of these, say so before you buy rather than after — we would rather lose the sale than misrepresent it.

Reporting a vulnerability

Email security@wflowprocess.app with enough detail to reproduce. We will acknowledge within 3 business days. Please do not test against other people's workspaces, run denial-of-service attacks, or access data that is not yours — report it and we will investigate. We will not pursue legal action for good-faith research that follows this.