AnmeldenLoslegen

Tigby Auftragsverarbeitungsvertrag (AVV)

Stand: 2026-08-29

Dieser Auftragsverarbeitungsvertrag („AVV") ist Bestandteil der Tigby-Nutzungsbedingungen zwischen der neuraforce GmbH, Dora-Koch-Stetter-Weg 22, 18055 Rostock, Deutschland („Auftragsverarbeiter", „Tigby") und dem Kunden („Verantwortlicher"). Er regelt jede Verarbeitung personenbezogener Daten in Kundeninhalten nach Art. 28 DSGVO und wird bei der Registrierung akzeptiert.

1. Gegenstand, Dauer, Art und Zweck

  • Gegenstand / Zweck: Betrieb des Tigby-Dienstes für Agenten-Identitäten — Hosting von Agenten-Postfächern (Senden, Empfangen, Speichern), Betrieb von Tunneln (Transport von Datenverkehr zum Agenten des Kunden), Connectoren zu Drittplattformen (Bluesky, Mastodon), Vault (verschlüsselte Geheimnisverwaltung) sowie zugehörige APIs, Webhooks und Exporte.
  • Dauer: Laufzeit des Nutzungsvertrags (bei Beendigung gilt Ziff. 10).
  • Art der Verarbeitung: Speicherung, Übermittlung, Abruf, Spam- und Malware-Filterung, Löschung; keine Nutzung für eigene Zwecke von Tigby.

2. Datenarten und Kategorien betroffener Personen

  • Datenarten: E-Mail-Inhalte und -Metadaten; über Connectoren ausgetauschte Nachrichten und Profildaten; durch Tunnel transportierter Datenverkehr; im Vault gespeicherte Geheimnisse und Zugangsdaten; Webhook-Payloads.
  • Kategorien betroffener Personen: Mitarbeiter des Verantwortlichen und Betreiber der Agenten; Dritte, die mit den Agenten des Verantwortlichen kommunizieren (E-Mail-Korrespondenten, Nutzer sozialer Plattformen); Personen, deren Daten in Kundeninhalten enthalten sind.

3. Dokumentierte Weisungen (Art. 28 Abs. 3 lit. a)

Tigby verarbeitet Kundeninhalte nur auf dokumentierte Weisung des Verantwortlichen. Die über Konsole, API, CLI und SDKs vorgenommene Dienstkonfiguration gilt als Weisung. Tigby informiert den Verantwortlichen, wenn eine Weisung nach seiner Auffassung gegen die DSGVO verstößt. Ist Tigby durch Unions- oder mitgliedstaatliches Recht zu darüber hinausgehender Verarbeitung verpflichtet, teilt Tigby dies dem Verantwortlichen vor der Verarbeitung mit, sofern das Recht dies nicht verbietet.

4. Vertraulichkeit (Art. 28 Abs. 3 lit. b)

Zur Verarbeitung von Kundeninhalten befugte Personen sind zur Vertraulichkeit verpflichtet (vertraglich sowie als Personal eines Maildienstes nach § 3 TDDDG, Fernmeldegeheimnis).

5. Sicherheit (Art. 28 Abs. 3 lit. c, Art. 32)

Tigby trifft die in Anlage 1 (TOMs) beschriebenen technischen und organisatorischen Maßnahmen, insbesondere ausschließlich EU/EWR- Infrastruktur, TLS bei der Übertragung, Verschlüsselung ruhender Daten und Envelope-Verschlüsselung auf Anwendungsebene für Vault-Geheimnisse und OAuth-Tokens. Die TOMs dürfen an den Stand der Technik angepasst werden, sofern das vereinbarte Schutzniveau nicht unterschritten wird.

6. Unterauftragsverarbeiter (Art. 28 Abs. 2, Abs. 3 lit. d)

Der Verantwortliche erteilt die allgemeine Genehmigung für die unter Sub-processors gelisteten Unterauftragsverarbeiter, sämtlich im EU/EWR-Raum. Beabsichtigte Ergänzungen oder Ersetzungen kündigt Tigby mindestens 30 Tage im Voraus über die Unterauftragsverarbeiter-Seite und per E-Mail an die Kontoinhaber an. Der Verantwortliche kann innerhalb dieser Frist aus nachvollziehbaren datenschutzrechtlichen Gründen widersprechen; kommt keine Lösung zustande, kann der Verantwortliche den betroffenen Dienst kündigen. Tigby erlegt jedem Unterauftragsverarbeiter die Pflichten dieses AVV vertraglich auf und haftet für dessen Leistung vollumfänglich.

7. Rechte betroffener Personen (Art. 28 Abs. 3 lit. e)

Tigby unterstützt den Verantwortlichen bei Anfragen nach Art. 12–23 DSGVO durch die eingebauten Export- (Kontodaten als JSON, Mailboxen als mbox/EML + JSON) und Löschfunktionen (Konto und einzelne Identities). Direkt bei Tigby eingehende Anfragen betroffener Personen werden unverzüglich an den Verantwortlichen weitergeleitet und von Tigby nicht inhaltlich beantwortet.

8. Meldung von Verletzungen und Unterstützung (Art. 28 Abs. 3 lit. f)

Tigby meldet dem Verantwortlichen unverzüglich, nachdem ihm eine Verletzung des Schutzes personenbezogener Daten in Kundeninhalten bekannt wurde, mit den Informationen nach Art. 33 Abs. 3 DSGVO, sobald sie vorliegen, und unterstützt den Verantwortlichen unter Berücksichtigung der Art der Verarbeitung bei seinen Pflichten aus Art. 32–36 DSGVO (Sicherheit, Meldepflichten, Datenschutz-Folgenabschätzung, vorherige Konsultation).

9. Nachweise und Kontrollen (Art. 28 Abs. 3 lit. h)

Tigby stellt alle erforderlichen Informationen zum Nachweis der Einhaltung des Art. 28 zur Verfügung — vorrangig diesen AVV, die TOMs und das Verzeichnis nach Art. 30 Abs. 2. Kontrollen und Inspektionen, auch durch beauftragte Dritte, sind mit angemessener Vorankündigung (mindestens 14 Tage, ohne konkreten Anlass höchstens einmal jährlich) zu Geschäftszeiten, ohne Betriebsstörung und auf Kosten des Verantwortlichen zulässig.

10. Löschung und Rückgabe (Art. 28 Abs. 3 lit. g)

Bei Beendigung des Nutzungsvertrags — oder früher über die Löschfunktionen — löscht Tigby sämtliche Kundeninhalte innerhalb von 30 Tagen, soweit keine gesetzliche Aufbewahrungspflicht besteht. Der Verantwortliche kann Kundeninhalte vor der Löschung exportieren. Restkopien in verschlüsselten Backups laufen automatisch innerhalb von 90 Tagen ab und werden nur zur Notfallwiederherstellung eingespielt; bereits gelöschte Daten werden dabei erneut gelöscht.

Zwei Dinge überdauern eine Löschung planmäßig und fallen nicht unter diese beiden Fristen. Der Handle einer gelöschten Identity bleibt unbefristet reserviert, damit Mail, die weiterhin an einen gelöschten Agenten adressiert ist, nicht einem Fremden zugestellt werden kann. Und je Löschung wird ein Löschnachweis — Identity-IDs, Handles und Zeitstempel, keine Adressen und keine Kundeninhalte — unbefristet aufbewahrt, denn er ist das, woraus ein wiederhergestelltes Backup erneut gelöscht wird. Beides ist kein Kundeninhalt; Tigby verarbeitet beides als Verantwortlicher auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO und nicht auf Weisung des Verantwortlichen, wie in der Datenschutzerklärung dargelegt.

11. Drittlandtransfers

Die Verarbeitung durch Tigby selbst erfolgt ausschließlich im EU/EWR-Raum. Tigby übermittelt aus eigenem Antrieb keine Kundeninhalte in Drittländer und setzt keine Unterauftragsverarbeiter außerhalb des EU/EWR ein. Künftige Änderungen unterliegen Ziff. 6.

Übermittlungen, die der Verantwortliche anweist, sind davon zu unterscheiden und von diesem Satz nicht erfasst. Lässt der Verantwortliche Tigby auf einer verbundenen Plattform posten oder von ihr lesen (Ziff. 1), Datenverkehr durch einen Tunnel an einen Endpunkt des Verantwortlichen leiten, ein Ereignis an einen vom Verantwortlichen registrierten Webhook-Endpunkt zustellen oder Mail an einen vom Verantwortlichen adressierten Empfänger senden, so übermittelt Tigby Kundeninhalte an ein Ziel, das der Verantwortliche gewählt hat. Diese Ziele sind eigenständige Dritte und keine Unterauftragsverarbeiter Tigbys, und jedes von ihnen kann außerhalb des EWR liegen: ein *.bsky.social-Konto wird von einem US-Unternehmen betrieben, eine Mastodon-Instanz liegt dort, wo ihr Betreiber sie betreibt, und ein Tunnel- oder Webhook-Endpunkt liegt dort, wo der Verantwortliche ihn betreibt. Tigby schränkt sie geografisch nicht ein, denn Konto und Endpunkt bringt der Verantwortliche mit. Tigby ist damit für diese Übermittlungen nicht die übermittelnde Stelle; das ist der Verantwortliche, und die Prüfung nach Kapitel V DSGVO obliegt ihm.

12. Schlussbestimmungen

Es gilt deutsches Recht. Bei Widersprüchen zwischen diesem AVV und den Nutzungsbedingungen geht dieser AVV in Datenschutzfragen vor. Die englische Fassung (DPA) und diese Fassung sollen inhaltlich identisch sein.

Anlage 1: Technische und organisatorische Maßnahmen (TOMs)
Anlage 2: Liste der Unterauftragsverarbeiter

Anlage 1 – Technical and Organizational Measures (TOMs)

Dieses Dokument liegt bislang nur auf Englisch vor. Eine deutsche Fassung steht noch aus.

Art. 32 GDPR measures of neuraforce GmbH for the Tigby service.
Last reviewed: 2026-08-27.

1. Infrastructure and physical security

  • All processing on infrastructure in the EU/EEA operated by EU-owned providers: two dedicated servers (OVH, Limburg an der Lahn, Germany, ISO 27001-certified datacenters, separate buildings), a witness/monitoring VM (OVH, Limburg an der Lahn, Germany), backup storage (OVH, Germany) with a monthly encrypted copy at Scaleway (France).
  • Physical security, power, and network redundancy per the datacenter operator's certifications; no Tigby hardware outside these facilities.

2. Encryption

  • In transit: TLS for all external connections — web console, API, Tunnel endpoints, mail transport (STARTTLS/TLS; MTA-STS and TLS-RPT published), IMAP. Internal replication and node-interconnect traffic over a private network.
  • At rest: database and mail stores are encrypted with ZFS native encryption (AES-256-GCM) on the two dedicated nodes; the per-node key is sealed to that node's TPM 2.0 and released only on that machine, so an unattended reboot re-enters service without operator interaction. Swap is encrypted with a key regenerated at every boot; operational logs, which carry mail traffic data, reside on an encrypted dataset as well. This protects data on disks that leave the facility — returned, replaced, or disposed of; it does not protect a running machine, whose keys are necessarily in memory. Nor does it protect against a different operating system booted on the same machine: the key is bound to the TPM but not to a PCR policy, and Secure Boot is off, so the TPM releases it to whatever boots on that motherboard — the provider's rescue mode included. Control of the provider console is therefore part of the boundary of the seal, and is protected by the two-factor authentication required in §3. That is the price of a reboot that needs no operator, and it is stated here rather than left to be inferred. The witness/monitoring VM is not encrypted; what may reach it is bounded instead — no mailbox content, and traffic data only in the pseudonymized form described in §4.
  • Application layer: Vault secrets and Connector OAuth tokens are envelope-encrypted (AES-256-GCM, per-organization data keys wrapped by a host key held as a rootless-container secret); database access alone does not reveal them.
  • Backups: pgBackRest backups encrypted; the offsite monthly copy is encrypted before leaving the primary provider. The host key is escrowed offline (single sealed copy).

3. Access control

  • Administrative access restricted to named administrators (currently: the managing director) via SSH public-key authentication only; no password login; administrative access is logged.
  • Provider consoles (OVH, Scaleway, Mollie) protected with strong unique credentials and two-factor authentication.
  • Application access via API keys (admin- or identity-scoped), stored only as hashes, shown once at creation; console sessions are server-side with magic-link login.
  • One bounded exception to "only as hashes": an Identity's first API key and its mailbox password are held in the database in the clear from the moment provisioning mints them until the customer confirms receipt, and at most for a configured window (15 minutes at launch) after which a sweeper deletes them whether or not anyone confirmed. Nothing else is ever held in the clear, and neither value can be re-read once it is gone. Two calls bound that window and neither is the status resource: GET /api/identities/{handle}/identity-key hands the pair over, and POST /api/identities/{handle}/identity-key/ack is the confirmation of receipt that deletes them. The status resource a client polls while provisioning runs carries neither, so no credential reaches a caller that did not ask for one.
  • Services run as rootless containers under distinct unprivileged users; least privilege between components (the public tunnel listener runs outside the process that can decrypt the Vault).

4. Separation and pseudonymization

  • Logical tenant separation by organization ID at the application and database layer; per-organization encryption keys for secrets.
  • Two separate databases (application vs. mail store) in one cluster.
  • Operational logs reference internal IDs rather than content; mail content is never copied into logs.
  • The witness/monitoring VM holds cluster-quorum state, operational metrics referenced by internal ID, the log lines shipped from all three hosts (MTA lines included, retained 90 days) and application error reports. No mailbox content and no message bodies are stored on it, and no unredacted traffic data: mail addresses and client IP addresses are replaced by a salted HMAC on the sending host, before the line leaves it, so the collector never receives the value itself. The raw line stays on the sending host's encrypted dataset and is expired there after 30 days.
  • Log retention is therefore tiered at the redaction, not at "access" versus "security": unredacted log lines 30 days (the node journal, the only place an address is in the clear), redacted operational and security logs 90 days (the witness's stores). The short clock sits on the identifying data, which is the storage-limitation argument under Art. 5(1)(e); the reasoning is recorded in the architecture decision on the observation layer. ops/verify.sh asserts both numbers against what the machines are configured with.
  • That replacement is pseudonymization, not anonymization: the same value yields the same token, and the log store is therefore recorded as personal data in the Art. 30 records, not as anonymous operational data. It is a security measure under Art. 32(1)(a), and the measures that carry it are checked rather than promised — the infrastructure check asserts that the redaction key exists, is readable by root alone and is not exposed through the service environment, and a continuous-integration test runs the redaction rules against sample log lines including real MTA lines.

5. Integrity and availability

  • Two-node warm active-standby cluster with automatic failover (Patroni + witness quorum); synchronous database replication (RPO 0 in normal operation).
  • Point-in-time-recovery backups: WAL archiving, daily differential, weekly full; retention 30 days, offsite monthly copies retained 90 days; recurring documented restore tests.
  • Monitoring, alerting and external probing run on a third host that is not part of the failover pair (witness VM), so each node is observed from outside itself, and every host watches the others — a stalled alerting pipeline raises an alert of its own rather than reading as silence. All three machines are at the same location, so a site-wide outage is learned from the provider rather than from Tigby's own alerting; alerts are dispatched over paths that do not depend on the Tigby mail service. On-call: managing director.
  • Rate limiting and verification-coupled send limits against abuse; spam and malware filtering on inbound mail.

6. Data-protection procedures

  • Deletion concept: self-serve deletion (account and per-Identity) purges live data within 30 days; backup copies expire within 90 days; documented in the privacy policy and DPA.
  • Export: self-serve account (JSON) and mailbox (mbox/EML + JSON) export.
  • Breach response per the incident runbook (Art. 33: 72 hours to the authority; processor notice to customers without undue delay).
  • Records of processing maintained per Art. 30 (ropa).
  • Sub-processors bound by Art. 28 contracts; list published with 30-day change notice.
  • Personnel (future hires) bound to confidentiality and § 3 TDDDG telecommunications secrecy before access; onboarding/offboarding checklist with access revocation.
  • Software supply chain: dependencies pinned; deployments from version-controlled configuration via manual, logged CI scripts over SSH.

7. Review

These measures are reviewed at least annually and on every significant architecture change; the DPA permits evolution that does not lower the security level.