Skip to content
luftflow

Security and your data

What luftflow does today to protect your service and your callers' data, and what it doesn't have yet. Everything on this page describes the product as it is now.

Where we stand

luftflow is in early access and does not hold SOC 2, ISO 27001 or PCI DSS certification. We will list certifications here when we have them, not before.

During a pilot we answer your security questionnaire, walk your team through how the product is set up, and help you describe it to your regulator if your outsourcing rules ask for that.

To ask about security before a pilot, request early access and mention it in your request.

Where your callers' data goes

The editor, where your team builds and approves flows, is always hosted by luftflow. Sessions can run on luftflow's servers or on your own.

WhatHosted runtimeSelf-hosted runtime
Where sessions run On luftflow's servers. Ask us where they are hosted before you send customer data. On your servers, which answer your aggregator directly.
PINs and other typed answers Held in the live session on luftflow's servers until it expires, an hour after the last keypress. Left out of session logs. Held in the session store on your network until the session expires. Left out of session logs.
Full phone numbers Seen by the runtime to run the session. Masked in session logs, as 26097****001. Stay on your network. Masked before logs are sent to the editor.
Responses from your APIs Pass through luftflow's servers to fill the caller's screens. Stay on your network.
Session logs for traffic reports Screens reached, menu choices, masked numbers and API call paths and timings. Deleted after 30 days. The same logs, sent to the editor. Deleted after 30 days.
Flows, versions and scenarios Stored in the editor. Stored in the editor. The runtime downloads the versions you put live.

Flows, scenarios and test answers are stored in the editor, so use made-up numbers and responses in them, never real customer data.

Controls in the product

These are built into luftflow for every team, with nothing extra to buy.

Roles
Viewers can look and dial. Editors change flows and put versions on staging. Only admins put versions live, manage members and hold secrets. Owners manage other owners.
Publishing stops on a failure
A version can't be published while the flow has errors or any saved scenario fails.
Versions never change
A published version is frozen together with the checks and scenario results it passed. Rolling back puts an earlier version live in one step.
Going live takes an admin
Putting a version live needs an admin and a confirmation. Turn on the two-person rule, and the person who published a version can't be the one who puts it live.
An audit log for your risk team
Every publish and every deploy, with who did it, when, and which checks and scenarios passed, downloads as a spreadsheet.
Staging and live are separate
Each has its own callback URL, access key, variables and secrets. Secrets are encrypted in the database.
Session logs keep little
Phone numbers are masked, what callers type on input screens is left out, API calls are logged by path without query strings, and logs are deleted after 30 days.
A retry doesn't call your API twice
When an aggregator sends the same request again, the runtime answers from the session's record instead of repeating the call.
Alerts go where you choose
Traffic alerts post to a webhook you set, which must be a public HTTPS address.
Nothing is locked in
Download any flow as plain YAML at any time, keep it in git, and import it back.
Sign-in
Sign in with a passkey, or a password of at least 10 characters. Sign-in attempts are rate-limited and the site is served over HTTPS only.

Not available yet

So you can plan around them, here is what regulated teams often ask for that luftflow doesn't have today.

  • SOC 2, ISO 27001 or PCI DSS certification
  • Single sign-on, and a way to require passkeys or two-factor sign-in for everyone
  • A contractual uptime commitment
  • A signed, versioned bundle for a runtime that cannot reach the editor
  • Alerts by email or to paging tools; Slack and webhooks only for now

Keeping data in the country

Some regulators require payment or personal data to stay in the country, such as Nigeria's Central Bank from 1 January 2027. The self-hosted runtime keeps sessions on your network; the diagram on our home page shows what crosses the border.

This is background, not legal advice. Check what your regulator expects with your compliance team.

Last updated September 16, 2026.