What we can prove today
Written the way you can check it: a document to read, a header to inspect, a behaviour to test.
Legal documents, versioned
Six of them, per language: terms, privacy, cookies, responsible use, the data processing addendum and the commercial agreement. Each one carries the date it changed.
LGPD and GDPR in practice
Cookie consent before any non-essential script, a data processing addendum for whoever needs one, and a published channel for a data subject request.
Hardened after a real pentest
The platform went through a penetration test and the findings were fixed, not filed. The edge rules, the closed direct origin and the storage policy all come from that round.
What we do not have yet
Stated plainly, because a security page that only lists strengths is the one nobody should trust. If any of these is a requirement for you, tell us before you build on top of the platform.
- SOC 2 Type II and ISO 27001. We are not certified, and we do not have a report to send you.
- Data residency by region. Everything runs in a single region today; you cannot pick where your app's data lives.
- A published bug bounty. Reports are welcome and answered, but there is no reward programme behind them.
What protects the data inside your app
Your app's users are not our users, and their data is not ours to look at. These are the mechanisms that hold that line.
Data separated per account
Every project's data is isolated per tenant, and access to each record is decided by the app's own rules — public, signed-in, by role or by ownership.
Card data never touches your app
Payments go through Stripe, Pagar.me and Mercado Pago. The card fields are rendered by a hosted vault component; the card number does not pass through the code the AI wrote.
Builds run isolated
An app's build runs in an ephemeral container with no host environment, dropped capabilities and CPU, memory and time limits. Secrets stay outside it — the sandbox never sees one.
Files served safely
Active document types are forced private and delivered through short-lived signed URLs; videos are never public links.
Secrets are held, not copied
Integration credentials live in encrypted rows on our side and are injected at call time. Snapshotting an app into a template never carries a secret with it.
Edge protection
The published apps and the platform sit behind Cloudflare, with HTTPS, rate limiting and bot protection in front of them.
What protects the platform around it
The part you never see, and the part that decides whether an app generated by an AI is safe to publish at all.
A scan that can block the publish
Before an app goes live, the generated code is checked for a secret written into it and for an access rule that would leave a table open. Publishing stops rather than shipping either.
The build container holds no secret
Each app is built in a container that is created and destroyed, with dropped capabilities, no host environment and no platform key inside it. The only thing that comes out is the compiled folder.
The direct origin is closed
The platform answers only through Cloudflare, with a web application firewall and rate limiting in front. The underlying service address returns 404 to anyone who finds it.
Credentials are encrypted, never echoed
Integration and store credentials are encrypted at rest and injected at call time. Once saved, no screen and no API ever reads one back — rotating means writing a new one.
Second factor and passkeys
Your account takes a second factor by app, by e-mail or by passkey. The staff tools behind it require the second factor for every sensitive action, not once per session.
Twenty-four permissions, five roles
Who can invite, who can spend credit, who can publish. Publishing is its own permission, so somebody can build all week without being able to put it in front of customers.
Where the AI is not allowed to go
The objection that actually matters about a generated app is not whether the code compiles. It is what the model and the agent are able to reach.
The agent inherits the caller, never more
The AI inside your published app runs under the permission of whoever called it. It cannot read a record its caller could not read, which is what stops a prompt from becoming a data leak.
The model never sees a credential
A connector call leaves from our side with the key attached. The key is not in the prompt, not in the generated code and not in the browser.
An outbound call cannot be redirected inward
A connector's address is validated before the request leaves, redirects are not followed and the DNS answer is pinned, so it cannot be walked to an internal address.
Questions we get asked
Reporting a vulnerability
Email security@fabapp.com. Our disclosure channel is published at /.well-known/security.txt, following RFC 9116. Please give us a chance to fix it before publishing.
Documents: The terms of use, the privacy policy, the data-processing addendum and the responsible-use policy are published in full and versioned.