The short version
- We do not store your prompts or the models' answers, and we do not train on them.
- Requests are processed by third-party inference providers, who necessarily see their content.
- We store your account, hashed credentials, and per-request usage metadata — tokens, cost, timing, and the country a request came from (not the IP address).
- No analytics, no ad trackers. One sign-in cookie.
- Account deletion and export are done by hand during the beta: write to us.
- We do not sell personal information.
The summary helps you read the document; it does not replace it. These are beta documents and have not yet been through a full legal review.
Who this covers#
This policy describes how Hummingbird Security (“we”) handles information when you visit hmbrd.dev, apply for access, hold an account, or call the API at api.hmbrd.dev. We are the party that decides how that information is used.
It is written to match what the system actually does today, during the private beta. Where the answer is “we have not built that yet”, it says so.
Your prompts and the models’ answers#
This is the part most people come here for, so it goes first.
- We do not store the content of your requests or the responses. Prompts, messages, tool calls and completions pass through our relay in memory so that it can forward them, count tokens and stream the answer back. They are not written to our database or our logs.
- We do not use your content to train models, and we do not sell it.
- Your content is processed by third-party inference providers. We do not run the model hardware ourselves during the beta: the relay sends each request to an external provider that runs the model, and returns what comes back. That provider necessarily sees the content of the request.
What we cannot promise. Inference providers handle requests under their own terms, which may include short-term logging for abuse prevention or debugging. We choose providers with that in mind, but we do not control their systems, so we are not making a “zero-logging” or data-isolation claim on their behalf. Do not send content that you could not accept a third-party processor seeing — in particular, avoid sending secrets, and think before sending other people's personal data.
We send providers the request itself. We do not add your account name, login, email or API key to it.
What we store#
| Data | What exactly | Why |
|---|---|---|
| Account | Display name, login, a salted hash of your password, optionally an email address, account status, and internal notes and tags our team adds (for example how you were invited). | To give you an account and operate it. |
| API keys | A hash of each key, its first characters for display, name, spend limit, expiry, when it was created, last used and revoked. Never the key itself. | To authenticate requests. |
| Key share links | The key encrypted so that it can only be opened with the link and its PIN, neither of which we store. The ciphertext is erased when the link is opened, locked or no longer needed. | To hand a key to someone, once. |
| Usage records | For each request: time, which key and model, endpoint, whether it streamed, token counts, cost, latency, HTTP status, an error code if any, which infrastructure served it, and the country the request came from (derived from the IP address by our network provider; the IP address itself is not stored). No request or response text. | To bill you, show usage in your dashboard, and run the service. The country is kept for abuse prevention and sanctions compliance. |
| Balance ledger | Every credit added to your account: amount, paid or bonus, pack, date, who applied it, and a note. | Accounting, and resolving billing questions. |
| Invitations | The suggested login, the credit attached, expiry, and which account the invitation became. | To issue and honour invitations. |
| Admin audit log | Actions our team takes on accounts — top-ups, suspensions, key revocations — and who took them. | Accountability for our own access. |
Applications for access
When you submit the early-access form, what you enter — Telegram handle, email, who you are (and your company, if you name it), your use case and expected volume — is delivered to our team's Telegram chat through a Telegram bot. It is not stored in our database. We use it to review the application and to contact you about it.
Payments
During the beta, top-ups are arranged directly with our team on Telegram. We do not operate a checkout and do not hold card details. We keep the record of the top-up in the ledger, and whatever the conversation and the payment method themselves reveal.
Technical logs
The service runs on Cloudflare. Like any web service, its infrastructure produces short-lived operational logs with technical request data — time, path, status and, at the network level, IP address and user agent. They do not contain request bodies. We use them to debug and to defend the service; we do not build profiles from them.
Cookies and browser storage#
There are no analytics, advertising or third-party tracking scripts on this site, so there is no consent banner. What we set is needed for the site to work:
| Name | Kind | Purpose |
|---|---|---|
hr_console | Cookie, up to 7 days | Keeps you signed in to the dashboard. Signed, HTTP-only. |
hr:intro | Session storage | Remembers that the landing page intro has already played in this tab. |
hr_admin | Cookie, up to 12 hours | Our team's sign-in to the admin console. Not set for customers. |
Cloudflare may set its own strictly necessary cookies to protect the site from abuse.
How we use information#
- To provide the service: authenticate requests, route them, meter and bill them.
- To show you your own usage and balance.
- To contact you about your application, your account, billing, or important changes.
- To keep the service secure, prevent abuse, and enforce the Acceptable Use Policy.
- To meet legal and accounting obligations.
We do not sell personal information, do not use it for advertising, and do not make automated decisions about you that have legal effects.
Where the law asks for a legal basis: we process account, usage and billing data to perform our contract with you; security and abuse-prevention data on the basis of our legitimate interest in running a safe service; and some records because the law requires us to keep them.
Who else is involved#
- Inference providers receive the content of API requests in order to run the model, as described above. We do not disclose who they are.
- Cloudflare hosts the website, the API and the database, and carries all traffic to them.
- Telegram carries access applications and conversations with our team about top-ups and support.
- Authorities, when we are legally required to disclose information, or when it is necessary to protect someone from serious harm. Because we do not store request content, we cannot hand over what we do not have.
- A successor, if the service is transferred to another operator — under this policy or one no less protective, and with notice to you.
These parties operate in several countries, so your information may be processed outside the country you live in.
How long we keep it#
- Account, keys, usage records and ledger — for as long as the account exists. There is no automatic expiry yet.
- After an account is closed — we delete or anonymise what identifies you on request, except billing and ledger records we need to keep for accounting, tax or dispute purposes, which are kept only as long as those purposes require.
- Unused invitations expire after 12 hours; key share links after the period chosen when they were created, and their encrypted contents are erased once used.
- Applications — kept in our team chat while the beta is running; ask and we will delete yours.
- Technical logs — days, not months.
Not built yet. The dashboard has no self-serve “delete my account” or data export. During the beta these are done by hand: write to us and we will do it.
Security#
- Passwords are stored as salted, iterated hashes (PBKDF2); API keys as hashes. Neither can be read back.
- Invitation and share-link tokens are stored only as hashes; a shared key is encrypted under a key we do not hold.
- Traffic is encrypted in transit with TLS.
- Access to production data is limited to the people who operate the service, and their actions on accounts are logged.
No system is perfectly secure. If we learn of a breach that affects your data, we will tell you without undue delay. If you find a vulnerability, please report it to access@hmbrd.dev.
Your choices and rights#
Whatever country you are in, you can ask us to: tell you what we hold about you, give you a copy, correct it, delete it, or stop using it for a particular purpose. Depending on where you live, the law may give you these and further rights — including to object, to restrict processing, and to complain to your data protection authority.
Write to access@hmbrd.dev from a contact we can tie to your account, or message us from the Telegram account you applied with. We answer within 30 days. We do not charge for this and will not treat you differently for asking.
In the dashboard you can already see your usage and ledger, and create or revoke keys yourself.
Children#
The service is for adults. It is not directed at anyone under 18 and we do not knowingly open accounts for them. If you believe a minor has an account, tell us and we will close it.
Changes#
This policy will change as the beta develops — in particular when self-serve payments or new providers are added. The current version is always on this page with its effective date. If a change materially affects how your information is used, we will announce it in the dashboard or contact you before it takes effect where we reasonably can.
Contact#
For any privacy question or request:
- Email: access@hmbrd.dev
- Telegram: toxuv.t.me