1. Who can reach your data
Your workspace is the boundary. Every request is checked for who is calling, which workspace, what their role allows, and whether the resource belongs to that workspace's project. An id from another workspace gets the same answer as an id that does not exist, before any of its data is read.
- Owner and admin — everything in the workspace, including members, API keys and the audit log. Only the owner manages billing and can delete the workspace.
- Developer — projects and their resources, environment variable values, database queries and exports, function source, and download links of up to 7 days.
- Viewer, and read-only API keys — read access to deployed source and repo files (with .env files and private keys withheld), stored files through 15-minute links, your app's users' and buyers' emails, the email log, memory, agent runs and build logs. Never environment variable values, signing secrets, function source or database rows.
The AI connector acts with your role, through the same API, and never returns environment variable values. A read-only connector cannot change anything.
A download link works for whoever has it until it expires. Deleting the file stops it. Give each person and each app the narrowest role or key that works: a key can be read-only, limited to one project, or both.
2. How customers are kept apart
| Layer | Separation |
|---|---|
| Every API call | Your credential resolves to one workspace. Resources are found through project and workspace, never by id alone. |
| Databases | Each database is its own database. SQL in one can never reach another. |
| Storage | Each bucket is its own bucket, and a signed link covers one file in one bucket. |
| Vector search | One index per collection. |
| Memory | Kept per store and scope in Harakumo’s own database. Searches never cross scopes. |
| Functions | Each runs as its own isolated edge program, with only its project’s environment variables and no access to platform storage. |
| Static sites | Served by a program Harakumo writes, which reads only its own deployment’s files and keeps its own edge cache under a secret name. |
| Server apps | Each deployment runs in its own container. |
| Sign-in for your app | One user pool per project, with its own signing secret. |
| Payments | Buyers pay into Harakumo’s processor account. Each project’s share is tracked in a ledger, and withdrawals go only to the payout account the workspace owner connected. |
| Each workspace sends from no-reply@harakumo.com or from its own verified domains, with its own log and suppression list. | |
| Domains | Each root domain has one owning workspace. No other workspace can add a hostname under it. |
A static site gets changes to the program that serves it, such as its own edge cache and its HTTPS redirect, when it is published again or when we refresh every live site.
Not yetharakumo.app is not yet on the Public Suffix List, the list browsers use to keep sites under one domain apart. Until it is, browsers treat every harakumo.app address as the same site for cookies, so another app there can set a cookie your app receives. Where that matters, serve your app from your own domain.
3. Passwords, keys and secrets
- Passwords, yours and your app users': salted PBKDF2-SHA256 hashes. We never store the password itself.
- Sessions, API keys, connector tokens and sign-in client secrets: SHA-256 hashes. A new key or secret is shown to you once.
- Two-factor recovery codes: hashed, and each works once.
- Environment variables, sign-in signing secrets and payment webhook secrets: deploys and token signing need the values themselves, so we keep them. Viewers and read-only keys never see them, the AI connector never returns environment variable values or webhook secrets, and functions receive them as encrypted secret bindings.
- A sign-in pool's signing secret is returned once to whoever creates the pool, so the app can store it: a developer in the dashboard or a full-access API key. When an AI assistant adds sign-in through the AI connector, the signing secret and the client secret are saved straight into the project's environment variables instead, and the assistant gets only their names. After that, developers, admins, the owner and full-access API keys can show the signing secret again, and each time is written in your audit log.
Being switched onEncrypting environment variables, sign-in signing secrets, payment webhook secrets and team invitation links with a key kept outside our database. Until it is on, they are stored readable in our database.
Being switched onSealing the secrets behind authenticator-app codes with a separate key. Until it is on, they are stored readable in our database.
4. What Harakumo staff can see
- No one at Harakumo can sign in as you. There is no "view as customer" feature.
- Our staff need two-factor sign-in for every page and action in our admin tools. Every admin action that changes a customer's account, money or data also asks for a fresh code from their authenticator app. Two actions ask for no fresh code: marking a message sent to us through our contact form as new, read or archived, which changes nothing in any customer's account, and revealing a buyer's email on one of your disputed payments, which changes nothing and shows in your audit log.
- Our admin tools show account and operational details: members' names, emails, roles and two-factor state, recent sign-in IP addresses and browsers, connected AI assistants, API key names and when they were last used, your audit log, resource names, counts, sizes and status, commit messages, and the last lines of a deploy's build log. The buyer's email on a disputed payment stays hidden unless a staff member reveals it.
- They do not show your database rows, stored files, source code, environment variable values, your app's user list, the emails you send, or your AI prompts.
- Every change our staff make to your workspace through our admin tools is recorded in your audit log, marked as Harakumo staff.
- When our staff open your workspace in our admin tools, or its apps, payments or audit history, or the account page of one of its members, or reveal a buyer's email, your audit log shows "Harakumo support viewed …", marked as Harakumo staff. Looks at the same page within 10 minutes can show as one entry.
- The people who run Harakumo hold the credentials for the systems your data is stored on, as at any cloud provider.
Not yetSome looks are not in your audit log: most lists that cover many workspaces at once, such as search results and the list of recent publishes, and access through our infrastructure credentials, our backups or our maintenance scripts.
5. Encryption
- In transit: HTTPS on every harakumo.app address and on your own domains, with certificates handled for you. Static sites and the Harakumo dashboard redirect plain HTTP to HTTPS and send HSTS.
- At rest: databases, file storage and key-value data are stored on infrastructure that encrypts data at rest.
Not yetServer apps and functions still answer plain HTTP as well. Browsers reach harakumo.app addresses over HTTPS anyway; on your own domain, or from a script or another server, call them with https://.
6. Payments
Buyers pay on a hosted checkout page, so card numbers never reach Harakumo or your app. We keep the buyer's email and country with each payment. Payment records are kept after a project is deleted, as the law requires.
7. AI
When you use the AI Gateway, your prompt and the answer go to the company that makes the model: the model you name, or, with harakumo-1 (the default when no model is named), the first available model in its order, which moves to another company's model if one fails. You can switch any model off for your workspace. Embeddings and edge models run on our infrastructure provider. Harakumo's request log keeps the model, token counts, cost and timing, never the prompt or the answer, and deletes it after 30 days. Agent runs keep their input, output and each tool call so you can review them, until you delete the agent. We do not train AI models on your code, content or prompts. What a model company does with API traffic is set by its own terms.
An agent sends the model its instructions and whatever its tools read, such as repo files, memory or query results. Its tools never read environment variable values.
8. Logs and how long we keep them
- AI request log: model, tokens, cost and timing, never the prompt or the answer. Deleted after 30 days.
- Agent runs: input, output, and each tool call's arguments and results. Kept until you delete the agent.
- Email log: recipient and subject, never the body.
- Audit log: kept for the life of the workspace.
- Sessions: the IP address and browser of each, shown in Settings. A session lasts 30 days.
- Backups of our own database: kept to recover from failures. Each new backup is encrypted.
Being switched onEncrypting or deleting the older backups, made before backups were encrypted.
Not yetA set period after which backups are deleted. We will state how long backups are kept here once the period is set.
9. Deleting and taking your data with you
When you delete a project, a workspace or your account, it is removed from production systems straight away, apart from the gaps listed below, and cannot be recovered. What stays: payment records, as the law requires; your workspace's audit entries, for as long as the workspace exists; and copies in our backups until those backups are deleted.
To take your data with you, download any database as a .sql file, read your code file by file, list your app's users through the API (without password hashes), and ask us for a copy of the personal data we hold about you.
Not yetA few kinds of data can outlast a delete today: a server app's container that fails to stop, for any of the app's deployments, because a failed stop is not reported; the containers of a server app's oldest deployments, which a delete does not reach; the container of a server app deployment you delete on its own, with the environment variable values it was started with, which neither that delete nor deleting the project later removes; the files of a static site deployment you delete on its own, if the site is serving it or its publish failed, which stay until you delete the project; a stored file of your sites, uploaded code, builds or repos whose delete fails, because we do not yet check each file's result; a repo's history, because deleting a repo can report success when its history was not removed; and a deleted workspace's email sending domains. We are closing each of these.
10. Where your data lives and who processes it
You can't choose a region yet. Your data is processed by our infrastructure provider (hosting, databases, storage and email delivery), our payment processor, our domain registrar, and the AI model companies whose models you use.
Not yetA published list of these companies, and data-processing terms you can sign.
11. Certifications
Harakumo does not hold any security certification or independent audit report yet. When we do, it will be listed here.
12. Reporting a security issue
Email security@harakumo.com (also listed in /.well-known/security.txt). Include steps to reproduce, and give us a chance to fix the issue before sharing it publicly. For anything else, contact us.