Security

You don’t need to be a security expert to build with Highwind: good practices are applied by default, while building and at publish time. This page explains concretely what Highwind does to protect your account, your keys, your apps and their users’ data.

At a glance

Every project isolated

Each app is built in its own isolated environment. The agent only has a few specific tools there.

Apps on a separate domain

Published apps are served on highwind.site, never on the platform’s domain highwind.app.

Encrypted keys, server side

Your keys are encrypted, never shown again, never shown to the agent, and read only by your app’s server.

Checked before publishing

Database flaws and phishing pages are looked for before every release. A serious problem blocks publishing.

Project isolation

• One environment per project. Each project runs in its own sandbox, separated from other projects and other accounts. What runs in one project’s preview can’t reach another project.
• An agent with limited tools. The agent only has a small number of tools (read and write project files, check the build, ask for a key…). It never has access to your secrets or to the platform’s keys: the files holding the preview’s keys are hidden from it and aren’t saved in versions.
• One build at a time. An account runs only one request at a time, with usage limits (messages, projects, publishes) and a global spending cap that suspends generation if things run away.

Published apps on a separate domain

Highwind lives on highwind.app; the apps you publish live on your-app.highwind.site, a separate domain.

• A cookie set by a published app can’t be read by the Highwind platform: your Highwind session stays out of the apps’ reach.
• A malicious app can’t pass itself off as Highwind or put the platform at risk.
• The service that serves published apps has no access to Highwind’s database.
• Highwind and every published app are served over HTTPS.

Your keys and secrets

The API keys you add (in a chat card, on the Connectors page or in a project’s secrets) are protected at every step:

Protection	What it means
Encrypted	Values are encrypted in the database (AES-256-GCM) and never returned by Highwind’s API.
Never shown again	Once saved, a secret key is no longer visible in the interface: to change it, you replace it.
Never shown to the agent	The agent only knows whether a key is set. It neither sees nor copies its value.
Server side only	Only your app’s server (/api routes) reads keys. They’re never sent to visitors’ browsers.
Scoped to projects	A key only works in the projects you link it to.
Tested without side effects	Checking a key sends no email and creates no payment.

Only explicitly public values (a measurement ID, a public token restricted to your domain) are shown in clear and may be written into browser code. See Connectors and App secrets.

Caution

Never paste a secret key, a password or sensitive data into the chat: your messages are kept in the project’s history and sent to the AI model. Always use the cards and forms made for keys.

Accounts and outside access

• Invitation-only access. During the private beta, only invited addresses can use Highwind. An account that abuses the service can be suspended.
• Google Sheets: Highwind only asks Google for the drive.file permission, limited to the spreadsheets it creates for your apps. The app goes through the Highwind gateway: your Google tokens never leave Highwind. By default, the app can only add rows, not read them back. See Google Sheets.
• Read-only context sources. Notion, Linear and Figma are connected read-only: the agent only gets read tools. Kameleoon is read-only by default; edits need your explicit permission, and are always refused in Discussion mode. What the agent reads in a source is treated as information, never as an order. See Context sources.

Checks before every publish

Before an app is reachable on the Internet, Highwind checks it:

• Database flaw scan. If the app has a backend, its database is analyzed. A critical flaw (for example a table anyone can read and change) blocks publishing (“Publishing blocked”); less serious points are shown as Security points to check. The Fix with the agent button asks the agent to fix them.
• Phishing detection. The app’s code and copy are examined to spot pages that imitate a bank, a government agency or a well-known service to steal credentials or payments. An app judged dangerous is not published, and the Highwind team is alerted.
• A “Report” link on every app. Each published app shows a small “Made with Highwind” badge with a report button, open to all its visitors. See Acceptable use.

Your apps’ users’ data

When your app has a backend, its data is protected by default:

• Mandatory access rules (row level security). Every table has access rules: a user only sees and changes their own data. A table created without rules is refused.
• No accidental deletion. The agent can’t drop, empty or rename an existing table or column.
• Strong passwords: at least 8 characters for your apps’ user accounts.
• One database per app, hosted in Paris, and one folder per user for files.

Your share of responsibility

No tool can guarantee an app has no flaws. Highwind applies good practices by default and blocks the serious problems it detects, but you remain responsible for what your app collects and shows. Review what your app asks its visitors for, and only collect what you need.

Report a security vulnerability

Found a vulnerability in Highwind? Write to securite@highwind.app before making it public:

• describe the flaw, the steps to reproduce it and its possible impact;
• don’t access other users’ data and don’t disrupt the service;
• give the team time to fix it before any disclosure.

For a fraudulent app or illegal content, use the report form instead: see Acceptable use.

See also

PrivacyThe data Highwind keeps and where it's hosted.

Acceptable useWhat's forbidden, and how to report an app.

App secretsWhere your keys are stored and who can read them.

The databaseYour apps' accounts, data and access rules.