Security

This page describes how Himmel is designed to run. Hosting details are confirmed here when the service goes live.

Where your data lives

Himmel runs in the EU by default, on servers in Germany operated by Hetzner. The database, the application and the part that holds names all run there.

Accounts are kept apart by the database

Every account's rows are separated by the database itself, not by the application remembering to filter: each request runs as a database role that can see one account's data and nothing else. A request that has not said which account it is for sees nothing at all. Within an account, live and test are separated the same way: a request made with a test key sees and writes test data only, so nothing tried in test becomes part of the live record.

A few lookups read across accounts, and each names what it reads: who a key or a sign-in belongs to, the invitations waiting for a person, the name of the company that opened an account for its customer, and, for that company, where the accounts it opened stand - never their customers, people or decisions. Opening an account writes what an account is with the one role that may; everything else in it is written by the account's own.

That role can store a check and never change one. A changed answer is a new check that supersedes the old one, so the record of what Himmel answered, and when, is a permission of the database rather than a promise of the code.

Names are kept apart

Recipient names are replaced by tokens before anything is stored. The names themselves are encrypted, held in a separate part of the database, and read only through the one part of the service that resolves recipients; everything else — checks, the check log, alerts — works with ids. An email address or an IBAN anywhere else in a check, in a report of what became of one, or in a decision's reference is refused rather than stored.

A name is shown to a person and never to a key. In the console, admins and ops — the people who answer whether two records are the same person — see recipients' names; an API key, whatever it is allowed to do, is given ids, and a search by name from one is refused. A leaked key therefore cannot list who your company's recipients are.

A name is kept only as long as it is needed: a customer's until the fiscal year after the one they were last met in has ended, a person's in your account while they are in it, anything else 90 days after it was last used. A daily job deletes the rest; the evidence keeps ids, so it stands without them.

An uploaded policy document is masked before it is kept: the names you list, the names your earlier documents hid, the people in your account, every word that reads as a name, and every email address, IBAN and phone number become placeholders. The file itself is not kept. It is masked again before anything is drafted from it, against the people in your account as they are then. A name you find on reading it back is masked in the copy that is kept, a word hidden as a name that is none is shown again by an admin, and a document never sent to drafting can be withdrawn, its text with it.

Keys

API keys are 256-bit random values. Himmel stores only a keyed hash of each one, so a copy of the database does not hand over working keys, and a key is shown once, when it is created. Every agent gets a key of its own, so one can be revoked without touching anyone else's access, and an agent's key reads its own agent's answers, requests and alerts alone - never another agent's, your people, your settings or your playbooks.

No model answers a check

Every answer comes from rules your company confirmed, applied the same way every time. No check calls a language model. A language model is used only if you ask for a policy to be drafted from a document, only on masked text - the document, and for a revision the version it revises - and what it drafts runs only once your rule owner confirms it.

Evidence is kept

Every check is kept with everything behind it: the facts, the history it read, your settings, the rule versions and who confirmed them. The retention period for checks is a setting of your account, stated when your account is opened: the period your records must be kept for.

Sub-processors

Terms

Himmel provides information and controls, not advice: it checks transactions against rules your company has confirmed, and records that it did. There is no compliance guarantee, and no outside review: your company owns the decision to confirm a rule, and takes a rule to its own adviser if it wants one looked at. Liability is capped at the fees paid.

A data processing agreement is available on request.