Security and data

This page covers data ownership, the security measures behind the platform, who can see what, and — because your app is built by an AI assistant you bring yourself — what leaves Floot while you build.

Data ownership

You own 100% of your app:

Code

Complete code ownership.

Data

All app data belongs to you.

IP

Full intellectual property rights.

You can download a full SQL dump of your database at any time, on any plan: open your project on floot.com, go to the Services tab → Data, open a table, then use the cog icon in the table header → Database Settings → Export → Download Database. Code download is included on every paid plan, from the project-name dropdown in your project's top bar → Get Code.

Both are browser actions. Your assistant can read any file in the project and query the database for you through the connector, but the downloadable archive is built in your browser. Follow the preview link your assistant gives you, or find the project on floot.com, then use the menus above. See Code, data, and exports, or Self-hosting if you want to run the app yourself.

Security measures

Encrypted in transit

All traffic is served over HTTPS/TLS.

Encrypted at rest

Your database, your project source, and your files are stored on managed AWS and Neon infrastructure with provider-level disk encryption.

Secret handling

API keys and secrets are never typed into chat. Floot collects them through a dedicated form: your assistant hands you a one-time link, and you paste the key into a Floot page in your own browser. They are stored server-side, injected into your backend at runtime, and never returned to any client. At rest they carry the same provider-level disk encryption as the rest of the database; Floot does not add a second, application-level encryption layer on top of it.

Secrets are not visible to the AI

This is enforced by the shape of the data, not by instructions to the model: the integration list an assistant can see carries only a connection's name, type, description, and non-secret config values. The secret values are not part of that payload.

Internal access

Support access to a private project is limited to Floot staff, and is used to investigate an issue you have raised.

Who builds your app, and what it can see

The model writing your code is not Floot's. It is the assistant you connected — Claude, ChatGPT, Cursor, Codex or another MCP client — running under your own agreement with that provider. Floot's connector supplies the tools; the conversation, your prompts, and everything those tools return sit in that provider's context and are governed by their terms, not by Floot's. If you are reviewing Floot for procurement, this is the material point: your builder is a third party you chose and contract with directly.

What an assistant can read through the connector: your project's files, rows from your app's database (query_database, execute_sql, pull_database_schema), your app's backend logs (get_logs), and screenshots of the running preview. If your database holds real user data, that data reaches your assistant's context whenever you ask a question that requires it.

What it cannot do: read your integration secrets, or spend your money. Plan changes and every purchase are browser pages a person clicks, deliberately never tools an agent can call.

Your conversation is not stored on the project. What Floot keeps is two things: the files your assistant writes, and a running activity record of what it did — which files changed, which SQL ran, which images were generated — that the project's history and the Checkpoint panel are built from, and that stays for as long as the project does. Separately, a raw audit row per tool call — tool name, a capped summary of the arguments, the result — is kept for three days and then deleted. The chat around those calls never reaches Floot; it stays with your AI provider.

Privacy and visibility

Your projects

Preview links deserve their own line, because your AI assistant hands them out routinely. Every preview URL carries a token in its query string (?ptoken=…). That token is a view-scoped grant for exactly one project: it can read the project and interact with the running app, and it cannot write files, publish, or touch your account. It expires seven days after it was issued.

The no-login part is deliberate. These links are usually opened on a phone, inside a chat app's in-app browser, which carries no Floot cookies — a sign-in wall there would be a dead end. The trade-off is that anyone the link is forwarded to can open it until it expires, so treat a preview link the way you would treat a shared document link. Opening one while signed in as the owner still gives you your normal rights; the token never downgrades you.

For a private project:

• Your code and prompts are not visible to other Floot users
• No one else can duplicate it
• Access is limited to you, your collaborators, anyone holding a live preview link, and Floot staff as needed for support

Opening a project that someone else owns and shared with you requires a paid plan on your own account — the connector runs on your assistant's tokens, so the seat is what the plan pays for. Reading a public project is never gated; writing to a project you do not own is.

Your app's user data

Data your app collects — accounts, form submissions, uploads — is:

• Stored in your app's own Postgres database and file storage, on managed infrastructure with provider-level disk encryption
• Readable by the AI assistant you build with whenever a prompt requires it, which means it reaches that provider's context
• Your responsibility to handle in line with applicable law

Handling sensitive data

If your app handles healthcare, financial, or otherwise regulated data:

1. Consult legal counsel about your compliance requirements
2. Decide whether your assistant may query that data at all — a query you ask for sends real rows to your AI provider
3. Contact Floot to discuss your specific needs before you launch