Security

Your data, on your terms.

Who signs in, what each person can reach, and what is allowed to leave your organization — you set all of it, in a handful of switches rather than a project.

Access

Who gets in.

Security you switch on and verify, not a posture you have to take our word for.

Passwordless by default

Everyone signs in with a passkey held by their own device. There is no password to phish, reuse across sites, or lose in someone else's breach — because there is no password.

Two factors, not one

A one-time code to your address resolves the account, then the passkey proves it. A browser you mark as trusted can skip the code; the passkey is never optional.

Pro

Your identity provider

Point sign-in at your own OIDC provider and members arrive through it, so joiners and leavers stay one process and MFA policy stays where you already manage it.

Pro

Session length you choose

Set how long a session lasts before it re-asserts the passkey — anywhere from 12 hours to 14 days — instead of living with a default someone else picked.

Suspend someone in one click

Somebody leaves, or something looks wrong: suspend them and their sessions stop working straight away rather than when a token happens to expire. Their history stays intact and reactivating is one click.

Pro

Cut off outside access at once

Links and email invites you send outside the org are time-limited, and you set the ceiling on how long any of them may live. Switch org sharing off and every link already out there stops working immediately.

Authority

What they can touch.

Getting in is not the same as getting at everything. Reach is granted per app, per collection, and per capability — and the log says who granted it.

Pro

Four roles per app

Owner, editor, data editor and viewer. A new app is reachable by its owner and nobody else: access is a thing you grant, never something membership confers.

Pro

Grant a team at once

Put people in groups and grant the group, so access follows the team rather than a list you maintain by hand — and revoking is the same one move.

Max

Private data per person

Partition a collection so each person reads and writes only their own records inside one shared app. Everyone uses the same tool; nobody reads anyone else's rows.

Apps ask, you approve

A deployed app cannot read your member directory, send mail as itself, or go public until an admin allows it — per app, off by default, and never something the AI that built it can grant itself.

Max

Keys scoped to the job

Machine credentials for scripts and CI, limited to named collections with read and write set separately, rotated with a grace window so nothing breaks mid-cutover.

Pro

A log of who did what

Grants, invitations, member changes, publishes, backups, keys and plan changes, each with actor, target and time, kept for 90 days and filterable in the console.

Underneath

How we handle it.

Described by what it protects rather than how it is configured — naming our infrastructure would tell an attacker where to aim and tell you nothing useful.

In transit

TLS on everything — your browser to us, and every hop your data takes once it is with us. Nothing about your app or its data crosses a network in the clear.

In storage

Stored files, published app source and app backups are held in object storage that encrypts every object at rest.

Credentials

API keys, tokens and share links are stored one-way hashed — we can check what you present but cannot reproduce it. The few secrets that must stay reversible are encrypted under a key held outside the database.

Isolation

Your organization is the boundary, and each published app is served from its own opaque origin. One app's code cannot reach another app's data, or call the dashboard as whoever is viewing it.

Payments

Stripe hosts checkout. Card details never reach Appabl's servers and are never stored by us.

Deletion

Deleting an app removes its versions, stored files, collections and documents. You can also hold a collection to a rolling window, so records past it are cleared out for you instead of accumulating forever.

RecoveryPro and up

If you break it, undo it.

Every app keeps its own history, so a bad publish or a wrong bulk edit is something you reverse rather than something you rebuild.

Snapshots that match

One snapshot holds your app's published versions and every document in its collections, taken together. Restore it and the code and the data belong to the same moment — not today's database sitting behind last month's app.

Taken daily, and before a delete

Apps are snapshotted every day without you asking, skipping the ones nothing changed in. Deleting an app through your AI takes one first, automatically, and the dashboard offers one before it deletes — so changing your mind is a restore, not a support ticket.

Roll back a bad publish

Published versions are kept, and rolling back just moves the live one to whichever you pick. No redeploy, no rebuild, and the version list stays exactly as it was.

Restores land beside the original

A restore rebuilds the app as a new one rather than writing over what you have, so you can open both and compare before you move anyone across. The app you are rescuing is never at risk from the rescue.

Reporting a vulnerability

Found something? Tell us.

Send us what you found and how to reproduce it. We will acknowledge your report and keep you posted as we work it. We will not pursue legal action against anyone researching in good faith who gives us a reasonable window to fix the issue before going public.

security@appabl.ai

Build your first app by chatting.

Connect your AI, describe a tool, and share it with your team. Free to start, no card required.

See pricing

Appabl is currently available in the United States only.

Early access

Join the waitlist.

appabl isn't open to everyone yet. Leave your email and we'll let you know when there's a spot for you.

We use this to tell you when you can get in, and nothing else. What we keep, and for how long, is in our Privacy Policy.