Security

There is nothing to leak.

We don’t promise we can never be attacked; no honest company can. We promise something you can check: there is very little worth stealing, and what exists is locked down.

0 passwords

Never collected

No account passwords, one-time codes or card numbers.

AES-256-GCM

Encrypted at rest

Every provider token, bound to its website.

Read-only

By default

Anything more is an explicit owner grant.

One click

Revocable

Remove a person or a connection instantly.

What we do today

How we protect what we hold.

Everything in this table is running in production now.

ControlWhat it means
No passwordsWe never ask for or store account passwords, one-time codes, recovery codes or two-factor secrets for any platform.
Scoped connectionsCloudflare connects through an API token limited to reading zone, DNS and certificate details. GitHub connects as an app installed only on the repositories the owner chooses.
Encryption at restProvider tokens are encrypted with AES-256-GCM. Each token is bound to its website and provider, so it cannot be decrypted in any other context. Keys can be rotated without downtime.
Tokens stay on the serverDecrypted tokens are never sent to a browser, written to logs or included in pages. They are used only on our servers to read from the provider.
Least access firstConnections start read-only. Wider access, such as managing GitHub repository settings, requires an explicit grant from the website’s owner and can be withdrawn at any time.
Permission checks on every requestAccess is checked on our servers for every page and every action. A person given one website can reach that website and nothing else.
Plain language for clientsTechnical details are translated on our servers before reaching a client, using a fixed list of allowed sentences. If something isn’t on the list, it isn’t shown.
RevocationDisconnecting a provider deletes the stored token. Owners can also revoke it on the provider’s side, which stops it working everywhere.
Audit trailInvites, connections, revocations and changes are recorded with who did it and when.
What comes next

Earning trust in order.

These are on our roadmap, not running yet. We list them separately so nothing on this page overstates where we are.

  • A public security page and security contact (done)
  • Independent penetration test before write access is generally available
  • Bug bounty program, private then public
  • SOC 2 Type I, then Type II
On the roadmapNext
Hardware-backed keys

Envelope encryption with a managed key service, so encryption keys never sit next to the data.

Isolated token service

A separate service that holds tokens and makes provider calls, so the main app never sees them.

Approvals for changes

Any action that changes a customer’s account requires the owner’s approval, checked in our code.

Independent penetration test

Before write features become generally available.

Passkeys and multi-factor sign-in

Strong sign-in by default, with SAML single sign-on for larger teams.

SOC 2

Type I, then Type II, as larger customers require it.

Infrastructure

Where your data lives.

Application hosting

The Flizent app and this website run on Vercel. All traffic is encrypted in transit with TLS.

Database

Customer data is stored in managed PostgreSQL on Neon, hosted in the United States, encrypted at rest.

Files and DNS

Uploaded files are stored in Cloudflare R2. Our domain’s DNS is managed by Cloudflare.

The full list of service providers is in our Privacy Policy.

Responsible disclosure

Found something? Tell us.

If you believe you have found a security vulnerability, email us. We will acknowledge your report, keep you updated and credit you if you wish.

Good-faith research

Please give us reasonable time to fix an issue before disclosing it, avoid accessing other customers’ data, and don’t degrade the service. We will not pursue legal action against research done in good faith under these rules.

Access you can explain to a client.

No passwords required, ever.

Free for one website · Clients are always free