Privacy notice
authtoken is a Credential Broker for AI agents, operated by neuraforce GmbH, Dora-Koch-Stetter-Weg 22, 18055 Rostock, Germany (“we”). Managing director: Hans Wolff. Privacy contact: privacy@authtoken.com.
The entire authtoken infrastructure — servers, snapshots, logging — runs in Germany only. Personal data leaves it in two cases, and you are the one who triggers both: notifications to a phone you have paired and to a browser you asked to notify you travel through the push services of Apple, Google, Mozilla or Microsoft in the United States (§ 5).
1. Our two roles
- Controller (Art. 4(7) GDPR) for our own processing: your account, this website, security logs and the audit history.
- Processor (Art. 4(8), Art. 28 GDPR) for the contents of your vault: what you store as a Secret is your decision. We process those contents only as encrypted payloads — with one exception, which § 9 states in full: a Secret of type
totp, whose seed we must be able to read in order to compute your codes. We dispense all of them to your Agents only on your instruction. For a data processing agreement, write to us — the beta runs with individually known users.
2. What we process
| Processing | Data | Legal basis | Retention |
|---|---|---|---|
| Account and sign-in | Email address, password hash, TOTP factor, passkeys | Art. 6(1)(b) GDPR (contract) | Life of the Tenant |
| Vault contents | Secrets (encrypted), names of Targets and Identities | Art. 6(1)(b) GDPR | Life of the Tenant; versions until purged |
| Audit Events | Actions, IP addresses, machine fingerprints, Grant references — and, where an entry concerns a browser you switched on or ended, that browser's label from the row above — kept here too, for this row's 12 months, independently of the entry above and of its ending | Art. 6(1)(f) GDPR (security of the service) | 12 months, then hard-deleted |
| Security Events | Anomaly findings referencing Audit Events | Art. 6(1)(f) GDPR | Follow the Audit Events they reference |
| Sessions | Session records and timestamps | Art. 6(1)(b) GDPR | 7-day sliding window |
| Paired phone and push notifications | The phone's display name, platform, push address and time of last contact; per notification, the metadata of the pending decision at the detail level you chose (§ 5) | Art. 6(1)(b) GDPR | Device data: life of the Tenant — an unpaired phone, too, stays stored as the audit history's referent; only its push address goes earlier, once the push service reports it invalid. The message at the push service: until delivery or expiry (§ 5) |
| Notifications in a browser | Per browser you switch on for this: the address its push service issued, the two keys the browser generated itself, a plain-language label (“Firefox on macOS” — built by the browser from its own name and your operating system, not the raw user agent string), and the times it was switched on, last updated, last notified and ended; per notification, the same metadata as above, but encrypted (§ 5) | Art. 6(1)(b) GDPR | That browser is notified until you switch notifications off for it, sign out in it, revoke the entry in Settings, or the push service reports the address gone — the entry is then marked ended, its address and both keys are erased in that moment, and nothing further goes to it. What is left is the label and the times: that stays stored, like an unpaired phone, for the life of the Tenant as the audit history's referent; only deleting your Tenant removes it. The message at the push service: until delivery or expiry (§ 5) |
| Contact form | Name, email address, message | Art. 6(1)(f) GDPR (answering your enquiry) | 12 months after receipt |
| Operational logs | Server logs, may contain IP addresses | Art. 6(1)(f) GDPR | Weeks (size-capped) |
| Snapshots | Snapshots of the encrypted database volume, taken before each deployment | Art. 6(1)(f) GDPR (rollback point for failed updates) | Until ten later deployments have superseded it |
IP addresses and machine fingerprints in Audit Events are processed under legitimate interest (security of the service, Art. 6(1)(f) GDPR). The 12-month cap bounds that processing.
3. This website
These pages set no analytics or advertising cookies, load no third-party resources and send nothing to anyone else. Fonts and scripts are served from our own server. There is no tracking.
4. Cookies
We set three cookies, and all three are strictly necessary. None requires consent under § 25(2)(2) TDDDG — which is why there is no cookie banner here. A banner would ask permission that the law does not require for these three cookies.
| Name | Purpose | Lifetime |
|---|---|---|
__Host-authtoken_session | Keeps you signed in after sign-in | 7 days |
authtoken_lang | Mirrors the language you chose in your account, so the very first server response already arrives in it | 12 months |
sidebar | Remembers whether you collapsed the application's sidebar, or how wide you dragged it, so the page arrives that way | 12 months |
All three come into existence inside the application: the session cookie when you sign in, the language cookie when you set or change your account language, the sidebar cookie when you collapse the sidebar or drag its width. The public pages — landing page, download page, legal notice, this notice, contact form — set no cookie at all; the language switch there is an ordinary link that carries the language in the address. There are no analytics, advertising or tracking cookies, and we use no localStorage or comparable browser storage.
5. Recipients and location
All data is held in Germany, on a server provided by OVHcloud SAS in Limburg an der Lahn (DE1); OVHcloud is our processor for running that server. There is currently no copy on separate hardware; the snapshots, too, live on this server.
Two exceptions leave this server, and you trigger both. The first is the phone: if you pair one with the authtoken app to make decisions there, we send the notification for each decision to the phone maker's push service — Apple Inc. (Apple Push Notification service, for iPhones) or Google LLC (Firebase Cloud Messaging, for Android devices), both based in the United States. Both are our processors for this. Without a paired phone this transfer does not happen.
The second is the browser: if you switch notifications on for a browser under Settings → Devices, that browser takes out a subscription with its own push service and hands us the address. We send the notification to exactly that address — depending on the browser, to Mozilla Corporation (Firefox), Google LLC (Chrome and the other Chromium browsers), Apple Inc. (Safari) or Microsoft Corporation (Edge), all based in the United States. Which of those four recipients it is follows from your choice of browser, not from ours. Without a browser switched on, this transfer does not happen either.
What crosses to a phone's push service is set by the notification detail you choose in your settings; there the text travels in the clear. For a Retrieval Approval at “Full” (the default): the name of the requesting Agent, the Target and Identity, the type of Auth Method and the deadline; at “Agent only”: the Agent's name and the deadline. A Grant Request carries less — at “Full” the Agent's name and the Target, at “Agent only” the Agent's name alone; no Identity, no Auth Method, no deadline. At “A count only” every message carries only a count of decisions waiting. Secret values and Secret names are never transferred, at any level. At every level, “A count only” included, the push service also sees what the transport itself reveals: that the message comes from authtoken, which phone it goes to, an internal id of the decision (a message summarising several Grant Requests carries only its kind instead), the message's expiry and whether it concerns a Retrieval Approval or a Grant Request — and with that, when and how often decisions arise in your Tenant.
The same text goes to a browser, but encrypted — that is the difference from the phone. The notification's content is encrypted to keys your browser generated itself and never gives its push service; the push service carries a block of data it cannot read. What it sees is the transport: the subscription's address, which names that one browser; that the message comes from us; how long it should be held and how urgently delivered; a hash of the decision instead of its id (a message summarising several Grant Requests carries a fixed hash of its kind instead); the timing and frequency; and the size of the encrypted message — which we deliberately pad out to one of a few fixed sizes, so that it no longer follows the length of the text inside it: within one of those sizes, how long the text is, and how long the names in it are, can no longer be read off it. From the urgency and the holding time it can tell, as a phone's service can, whether the message concerns a Retrieval Approval or a Grant Request. So the detail level you chose governs what your browser displays; the push service reads none of the text, and learns from the size only which of those few it fell into — a notably longer notification still falls into a larger one.
What the browser keeps for this is two things: a service worker from our own server that does nothing but receive and display push messages — it stores nothing, opens no cache and intercepts no requests — and the subscription itself, which the browser manages and the switch dissolves again. What we store is its address, the browser's two keys, and the label and timestamps from § 2 — and when the subscription ends, in any of the ways § 2 names, the address and the two keys are erased there and then; only the label and the times remain, as the audit history's referent.
Retention: the push service holds a message only until delivery or expiry — for a Retrieval Approval until its own deadline (1 to 60 minutes, 15 by default), for a Grant Request 24 hours; the same bounds apply to a browser. What Apple, Google, Mozilla and Microsoft keep beyond that in their own operational logs we can neither bound nor verify: for the phone it is outside our contract with Apple and Google, and for the browsers’ push services there is no contract at all (see below).
Basis for the transfer (Art. 44 ff. GDPR). We looked all four recipients up in the official participant list of the EU-US Data Privacy Framework on 14 September 2026 — the date this notice names at the top as its last update:
- Google LLC is listed there as an active participant (EU-US certification with the status “Active - Re-certification under Review”, first certified 22 September 2016, current period to 13 September 2027). The transfer to Google — to an Android phone as to a Chrome browser — rests on the Data Privacy Framework adequacy decision (Art. 45 GDPR). For Firebase Cloud Messaging, the path to the phone, the Firebase Data Processing and Security Terms apply in addition, which also incorporate the EU Standard Contractual Clauses.
- Microsoft Corporation is listed there as an active participant too, with the status “Active - Re-certification under Review” (EU-US certification, first certified 12 August 2016, current period to 31 August 2027). The transfer to Microsoft therefore also rests on the adequacy decision (Art. 45 GDPR).
- Apple Inc. is not listed there, neither as an active nor as a withdrawn participant. For the path to the iPhone the transfer rests on the EU Standard Contractual Clauses (Art. 46(2)(c) GDPR), which Apple's own privacy policy names as the mechanism for transfers out of the EEA; the contractual basis is the Apple Developer Program License Agreement with its additional terms for the Apple Push Notification service.
- Mozilla Corporation is not listed there, under any status.
For two paths we can name you no basis, and we would rather say so than claim one: the browser push services of Mozilla (Firefox) and Apple (Safari). Web Push requires neither an account nor a contract with the push service — we send to the address your browser gave us, identifying ourselves only with a key we generated ourselves. So there is no contract into which Standard Contractual Clauses could be written, and for these two recipients no certification we could rely on either. What does bound this transfer is two things: the content is encrypted, so only the transport facts above arrive there, and it happens only for as long as you leave the switch on for that browser.
Two floors are in your hands: the detail level “A count only” limits every message to a number — on the phone as in the browser. And pairing no phone and switching no browser on triggers no transfer whatsoever — that costs the notification and nothing else; every decision can still be made in the web interface.
6. Deletion
You can delete your Tenant yourself. Domain data is hard-deleted immediately; the audit history is removed within 24 hours by the daily retention run, because the application deliberately holds no delete privilege on those tables. In the snapshots taken before each deployment, deleted data can persist until ten later deployments have superseded that snapshot; there is no calendar bound on that.
7. Your rights
You have the right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20) and objection (Art. 21). Access and portability are handled on request to privacy@authtoken.com within the statutory one month. Individual Secret values you can reveal yourself at any time under Sudo mode.
You may complain to the supervisory authority: Der Landesbeauftragte für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern, Schwerin.
8. Data protection officer
We are not required to appoint one (far below the § 38 BDSG threshold). The named contact is privacy@authtoken.com.
9. Security incidents
We notify the supervisory authority of reportable breaches within 72 hours (Art. 33) and affected users without undue delay (Art. 34) — including which Targets and Identities are affected, so you can rotate at the Target side.
Stated plainly: the contents of your Secrets are encrypted in your browser and on your machines under keys we do not have. neuraforce GmbH operators can reach the ciphertext, the names and structure of your Secrets, and TOTP seeds — which we must read to compute codes — but not the contents of any other Secret. The protections around what stays readable are organizational: named per-operator SSH keys, no shared accounts, logged access, and production access only for deploys and incidents. Lose your password and your Backup Code, and your encrypted Secrets cannot be recovered — not by us, not by anyone.