Auftragsverarbeitungsvertrag

Stand:

Die englische Fassung dieses Vertrags nach Art. 28 DSGVO dient der Information; bei Abweichungen gilt die deutsche Fassung.

Parteien

Verantwortlicher: das Unternehmen, das devboxes für seine Organization nutzt (im Folgenden „Kunde“):

Firma: ______________________
Anschrift: ______________________
Organization in devboxes: ______________________

Auftragsverarbeiter: Firat Özcan, Einzelunternehmer, Betreiber von devboxes, Leonhardstraße 44b, 38102 Braunschweig, Deutschland, privacy@devboxes.ai (im Folgenden „devboxes“).

§ 1 Gegenstand und Dauer

  1. devboxes verarbeitet personenbezogene Daten im Auftrag des Kunden, um den Dienst devboxes nach den Nutzungsbedingungen (im Folgenden „Hauptvertrag“) zu erbringen.
  2. Anlage 1 beschreibt Art und Zweck der Verarbeitung, die Arten personenbezogener Daten und die Kategorien betroffener Personen.
  3. Dieser Vertrag gilt, solange devboxes personenbezogene Daten des Kunden verarbeitet, mindestens für die Laufzeit des Hauptvertrags.
  4. Daten, die devboxes als eigener Verantwortlicher verarbeitet, fallen nicht unter diesen Vertrag. Dazu gehören die Anmeldedaten der Konten (Passwörter, Sitzungen und Anmeldeprotokolle; die Kennungen der Mitglieder in der Organization nennt Anlage 1), Abrechnungsdaten, Server-Protokolle zur Sicherheit des Dienstes und die Daten, die die Datenschutzerklärung beschreibt.

§ 2 Weisungen

  1. devboxes verarbeitet die Daten nur auf dokumentierte Weisung des Kunden, auch bei Übermittlungen in ein Drittland, es sei denn, das Recht der Union oder Deutschlands verpflichtet devboxes zur Verarbeitung. In diesem Fall teilt devboxes dem Kunden diese Pflicht vor der Verarbeitung mit, soweit das Recht dies nicht verbietet.
  2. Die Weisungen des Kunden sind der Hauptvertrag, dieser Vertrag und die Einstellungen, die die Inhaber und Admins der Organization in devboxes vornehmen, darunter verbundene Repositories, Tools, Modellanbieter, Runner, Zugriffsregeln für ausgehende Verbindungen und Löschungen. Weitere Weisungen erteilt der Kunde in Textform an privacy@devboxes.ai.
  3. devboxes informiert den Kunden unverzüglich, wenn es eine Weisung für rechtswidrig hält, und darf ihre Ausführung bis zur Bestätigung durch den Kunden aussetzen.

§ 3 Vertraulichkeit

devboxes ist ein Einzelunternehmen. Nur der Inhaber hat administrativen Zugriff auf die Daten des Kunden. Setzt devboxes weitere Personen ein, verpflichtet es sie vorher zur Vertraulichkeit, soweit sie keiner gesetzlichen Verschwiegenheitspflicht unterliegen.

§ 4 Technische und organisatorische Maßnahmen

  1. devboxes trifft die Maßnahmen nach Art. 32 DSGVO, die Anlage 2 beschreibt.
  2. devboxes darf die Maßnahmen weiterentwickeln, wenn das Schutzniveau nicht sinkt. Wesentliche Änderungen dokumentiert devboxes und teilt sie dem Kunden auf Anfrage mit.

§ 5 Unterauftragsverarbeiter

  1. Der Kunde genehmigt die in Anlage 3 genannten Unterauftragsverarbeiter.
  2. Der Kunde erteilt devboxes die allgemeine Genehmigung, weitere Unterauftragsverarbeiter einzusetzen oder bestehende zu ersetzen. devboxes informiert die Inhaber der Organization mindestens 30 Tage vorher per E-Mail. Der Kunde kann innerhalb dieser Frist in Textform aus wichtigem datenschutzrechtlichem Grund widersprechen. Können sich die Parteien nicht einigen, darf jede Partei den Hauptvertrag zum Zeitpunkt des Wechsels kündigen.
  3. devboxes schließt mit jedem Unterauftragsverarbeiter einen Vertrag, der ihm die Pflichten dieses Vertrags auferlegt, und bleibt dem Kunden für dessen Pflichterfüllung verantwortlich. Mit Monid und mit OpenAI für die System-Sessions ist ein solcher Vertrag noch nicht geschlossen (Anlage 3). devboxes schließt ihn ab oder setzt diese Unterauftragsverarbeiter nicht mehr für Daten des Kunden ein.
  4. Dienste, die der Kunde selbst wählt und mit denen er einen eigenen Vertrag hat, sind keine Unterauftragsverarbeiter von devboxes. Das gilt für den Modellanbieter, den die Organization verbindet, für Repository-Hosts, Chat- und Ticket-Tools und für die übrigen Dienste in Anlage 3, Teil B. devboxes übermittelt ihnen Daten auf Weisung des Kunden.

§ 6 Übermittlung in Drittländer

devboxes übermittelt personenbezogene Daten nur in ein Land außerhalb des Europäischen Wirtschaftsraums, wenn die Voraussetzungen der Art. 44 bis 49 DSGVO erfüllt sind, insbesondere auf Grundlage eines Angemessenheitsbeschlusses, etwa des EU-US Data Privacy Framework, oder der Standardvertragsklauseln der Europäischen Kommission. Anlage 3 nennt die Grundlage für jeden Unterauftragsverarbeiter. Ausgenommen sind derzeit Monid und OpenAI für die System-Sessions: Für ihre Übermittlungen in die USA ist noch keine solche Grundlage vereinbart (§ 5 Abs. 3).

§ 7 Unterstützung des Kunden

  1. Rechte betroffener Personen: devboxes unterstützt den Kunden mit geeigneten Maßnahmen bei der Beantwortung von Anträgen nach Art. 15 bis 22 DSGVO. Inhaber und Admins löschen Sessions selbst, außer den System-Sessions. Eine Person löscht ihre eigene Chat-Nachricht in ihrer Chat-App, und devboxes löscht dann seine Kopie, außer bei Telegram (Anlage 2, Nr. 10). Andere Anträge bearbeitet devboxes auf Anfrage an privacy@devboxes.ai. Wendet sich eine betroffene Person direkt an devboxes, leitet devboxes den Antrag an den Kunden weiter.
  2. Pflichten nach Art. 32 bis 36 DSGVO: devboxes unterstützt den Kunden bei der Sicherheit der Verarbeitung, bei Meldungen von Verletzungen, bei Datenschutz-Folgenabschätzungen und bei der vorherigen Konsultation, soweit dies die Art der Verarbeitung und die devboxes verfügbaren Informationen zulassen.

§ 8 Verletzungen des Schutzes personenbezogener Daten

devboxes meldet dem Kunden eine Verletzung des Schutzes personenbezogener Daten unverzüglich, spätestens 48 Stunden nachdem es von ihr Kenntnis erlangt hat, per E-Mail an die Inhaber der Organization. Die Meldung enthält, soweit bekannt, die Angaben nach Art. 33 Abs. 3 DSGVO. devboxes ergreift unverzüglich Maßnahmen, um die Verletzung einzudämmen und ihre Folgen zu mindern.

§ 9 Löschung und Rückgabe

  1. Nach Ende des Hauptvertrags löscht devboxes die Daten des Kunden innerhalb von 30 Tagen, soweit keine gesetzliche Pflicht zur Aufbewahrung besteht. Vorher kann der Kunde seine Daten über die CLI und die API abrufen oder einen Export bei privacy@devboxes.ai anfordern. Ausgenommen sind Medien, die Langfuse aus Traces auslagert; sie löscht devboxes nicht (Anlage 2, Nr. 10).
  2. Datensicherungen löscht devboxes nicht einzeln. Sie laufen nach höchstens 38 Tagen ab (Anlage 2, Nr. 9).
  3. devboxes bestätigt die Löschung auf Anfrage in Textform.

§ 10 Nachweise und Kontrollen

  1. devboxes stellt dem Kunden auf Anfrage die Informationen zur Verfügung, die zum Nachweis der Pflichten aus Art. 28 DSGVO nötig sind.
  2. Der Kunde oder ein von ihm beauftragter, zur Verschwiegenheit verpflichteter Prüfer darf die Einhaltung dieses Vertrags überprüfen. Eine Prüfung vor Ort meldet der Kunde mindestens vier Wochen vorher an. Sie findet höchstens einmal im Kalenderjahr während der Geschäftszeiten statt, es sei denn, ein konkreter Anlass rechtfertigt eine weitere Prüfung. Der Kunde trägt die Kosten seiner Prüfung. Die Rechenzentren der Unterauftragsverarbeiter prüft der Kunde über deren Nachweise.

§ 11 Haftung

Für die Haftung gilt Art. 82 DSGVO. Im Übrigen gelten die Haftungsregeln des Hauptvertrags.

§ 12 Abschluss und Schlussbestimmungen

  1. Der Vertrag kommt zustande, wenn der Kunde ihn unterschrieben an privacy@devboxes.ai sendet oder ihn dort in Textform per E-Mail annimmt.
  2. Bei Widersprüchen geht dieser Vertrag dem Hauptvertrag vor, soweit es um den Schutz personenbezogener Daten geht.
  3. Änderungen und Ergänzungen bedürfen der Textform.
  4. Es gilt deutsches Recht.
  5. Ist eine Bestimmung unwirksam, bleibt der Rest wirksam.

Ort, Datum: ______________________
Kunde: ______________________
devboxes (Firat Özcan): ______________________

Anlage 1: Gegenstand der Verarbeitung

Art und Zweck

devboxes ist ein Agent, dem der Kunde Arbeit aus seinen Chat- und Ticket-Tools, über die CLI oder über MCP übergibt. Für jede Aufgabe arbeitet ein Agent in einem isolierten Arbeitsbereich, entweder auf Servern von devboxes in Deutschland oder auf einem Rechner des Kunden (Runner). devboxes verarbeitet die Daten, um

  • Repositories des Kunden zu lesen, Code in Agent-Sessions zu laden und Pull Requests zu öffnen,
  • Anweisungen und Kontext an den Modellanbieter zu senden, den die Organization verbindet,
  • für jedes neue Projekt auf verwalteten Servern eine Onboarding- und eine Kalibrierungs-Session (System-Sessions) auf dem eigenen Modell von devboxes auszuführen, die das Repository lesen,
  • Nachrichten und Tickets in verbundenen Tools zu lesen und dort zu antworten,
  • Websuchen der Agenten auszuführen,
  • Session-Verläufe, Ereignisse, Artefakte, Chat-Unterhaltungen und das Gedächtnis der Organization zu speichern, damit Mitglieder Arbeit verfolgen und fortsetzen können,
  • Geheimnisse und Zugangsdaten der Organization zu verwahren und nur für deren Arbeit einzusetzen,
  • Fehler zu beheben und den Dienst zu betreiben.

Arten personenbezogener Daten

  • Kennungen der Mitglieder der Organization: Name, E-Mail-Adresse, Rolle, verknüpfte GitHub- oder Google-Konten
  • Inhalte von Repositories, einschließlich der Namen und E-Mail-Adressen in Commits und aller personenbezogenen Daten im Code
  • Aufgaben, Anweisungen, Session-Verläufe, Befehle, Werkzeugausgaben, Diffs und Artefakte
  • Nachrichten und Threads aus verbundenen Chat-Tools, Tickets und Kommentare aus verbundenen Ticket-Tools, einschließlich Nachrichten von Personen ohne devboxes-Konto
  • Gedächtnis-Einträge der Organization
  • Geheimnisse und Zugangsdaten, die die Organization hinterlegt
  • Suchanfragen der Agenten
  • Metadaten der Runner des Kunden

Besondere Kategorien nach Art. 9 DSGVO sind nicht Gegenstand der Verarbeitung. Gibt der Kunde sie in Aufgaben, Repositories oder Tools ein, verarbeitet devboxes sie wie die übrigen Daten.

Kategorien betroffener Personen

  • Mitglieder der Organization des Kunden
  • Personen, deren Nachrichten oder Tickets in verbundenen Tools stehen
  • Personen, deren Daten in den Repositories und Systemen des Kunden stehen, mit denen Agenten arbeiten

Anlage 2: Technische und organisatorische Maßnahmen

1. Standort

  • Alle Server von devboxes stehen in Deutschland: ein dedizierter Server im Rechenzentrum Falkenstein (FSN1-DC18) von Hetzner und Server der Hetzner Cloud am Standort Falkenstein. Verwaltete Aufgaben laufen nur auf diesen Servern.
  • Session-Artefakte und Datensicherungen liegen in Cloudflare R2 im Rechtsraum EU.

2. Zutrittskontrolle

  • devboxes betreibt keine eigenen Räume mit Servern. Den Zutritt zu den Rechenzentren regeln die Maßnahmen von Hetzner nach dessen Vertrag zur Auftragsverarbeitung mit devboxes (Anlage 3).

3. Zugangskontrolle

  • Server: Anmeldung per SSH nur mit Schlüssel, Passwörter sind abgeschaltet.
  • Betriebszugang zu Production läuft über Cloudflare Access und erreicht die Kubernetes-API, Prometheus und die PostgreSQL-Replikate. Prometheus und die Replikate sind für jedes Konto nur lesbar. Das Konto der Betriebsagenten liest auch die Kubernetes-API nur, ohne Secrets.
  • Nutzer melden sich mit E-Mail und Passwort (mindestens 12 Zeichen, bestätigte E-Mail-Adresse), mit einem per E-Mail gesendeten Code oder über GitHub oder Google an.
  • Zwei-Faktor-Authentisierung (TOTP) kann jede Person einschalten. Ist sie an, lehnt devboxes die Anmeldung per E-Mail-Code ab. Die Anmeldung über GitHub und Google schützt sie nicht.
  • Schreibende Aktionen im Admin-Bereich verlangen eine Anmeldung in den letzten fünf Minuten.

4. Zugriffskontrolle

  • Sessions und Ergebnisse sind nur für die Mitglieder ihrer Organization sichtbar, und ein kopierter Link erweitert den Zugriff nicht. Es gibt zwei Ausnahmen: Beiträge von devboxes in einem vertrauenswürdigen Kanal können ein widerrufbares Token tragen, das nur Lesen erlaubt, und ein Mitglied kann für eine Session eine Fragesitzung öffnen, in der bis zu 12 Stunden jeder mit ihrem Link und ihrem Passwort die Session liest und ihre Fragen beantwortet.
  • Rollen: Inhaber, Admin und Mitglied. Nur Inhaber und Admins fügen Zugangsdaten hinzu und löschen Sessions.
  • Der Inhaber von devboxes ist Superuser. Der Admin-Bereich ist nur ihm zugänglich, beantwortet alle anderen wie einen unbekannten Pfad, kennt keine Übernahme fremder Konten und protokolliert jeden Schreibzugriff mit Begründung.
  • Ein Agent einer verwalteten Aufgabe sieht Passwörter und Schlüssel nur als Platzhalter. Den echten Wert setzt devboxes erst ein, wenn eine Anfrage an einen erlaubten Dienst das System verlässt. Auf einem Runner des Kunden erhält die Aufgabe die echten Werte.

5. Trennungskontrolle

  • Jede verwaltete Aufgabe läuft in einer eigenen Sandbox unter gVisor, in einem eigenen Kubernetes-Cluster auf eigenen virtuellen Maschinen, getrennt von der Plattform.
  • Jede Aufgabe erhält eine eigene Netzwerkregel. Sie erreicht Paketquellen, GitHub, die Hosts ihres Modells, die Hosts von devboxes und die Hosts, die die Organization freigibt. Alles andere ist gesperrt.
  • Eine Sandbox endet spätestens zwölf Stunden nach ihrem Start.
  • Zugangsdaten jeder Organization sind mit deren eigenem Schlüssel verschlüsselt.

6. Verschlüsselung

  • Übertragung: Cloudflare verbindet sich mit den Servern von devboxes nur über TLS mit vollständiger Zertifikatsprüfung, mindestens TLS 1.2, und mit Authenticated Origin Pulls. PostgreSQL lehnt jede Verbindung ohne TLS ab.
  • Alle Laufwerke des dedizierten Servers sind mit LUKS2 verschlüsselt, außer der Startpartition mit Kernel und Startumgebung. Ein Laufwerk, das den Server verlässt, etwa bei einem Defekt oder Austausch, enthält keine lesbaren Daten.
  • Die Datenträger der Cloud-Server, auf denen verwaltete Aufgaben laufen, sind nicht verschlüsselt. Sie halten den Arbeitsbereich einer Aufgabe, bis ihre Sandbox endet.
  • Gespeicherte Zugangsdaten (Modell-Anmeldungen, Repository- und Tool-Tokens) sind zusätzlich mit dem Schlüssel der jeweiligen Organization verschlüsselt. Löscht devboxes den Schlüssel einer Organization, sind ihre Zugangsdaten auch in Sicherungen nicht mehr lesbar.
  • Geheimnisse der Organization liegen in Infisical, das jeden Wert verschlüsselt.
  • Kubernetes-Secrets sind im Datenspeicher des Clusters verschlüsselt.
  • Datensicherungen werden verschlüsselt, bevor sie den Server verlassen: PostgreSQL mit AES-256, ClickHouse und der Kubernetes-Datenspeicher mit age. Cloudflare verschlüsselt jedes Objekt in R2 zusätzlich mit AES-256.

7. Weitergabekontrolle

  • Websuchen verwalteter Sessions sendet devboxes nur mit dem Text der Anfrage, ohne Kontoname, E-Mail-Adresse oder Netzwerkadresse.
  • Fehlerberichte gehen an eine selbst betriebene Sentry-Instanz. Vorher entfernt devboxes Ausnahmetexte, Query-Strings und bekannte Geheimnisse.
  • Traces von Runs und Chat-Antworten gehen an eine selbst betriebene Langfuse-Instanz. Ihr Schlüssel erreicht keine Sandbox und keinen Runner.

8. Eingabekontrolle

  • Sicherheitsrelevante Aktionen schreibt die API in ein Protokoll, das nur ergänzt wird. Einträge laufen nach 180 Tagen ab.
  • Der Session-Verlauf hält Anweisungen, Befehle, Werkzeugereignisse und Diffs jeder Aufgabe fest.
  • Die Konfiguration der Cluster von Production ändert sich über geprüfte Commits, die Flux anwendet. Hosts, virtuelle Maschinen und Datenspeicher ändert der Inhaber mit Runbooks aus demselben Repository, Einstellungen bei Cloudflare und Infisical über deren Schnittstellen.

9. Verfügbarkeit und Wiederherstellbarkeit

  • Der dedizierte Server spiegelt seine beiden NVMe-Laufwerke (RAID1). Ein ausgefallenes Laufwerk oder ein fast volles Dateisystem meldet ein Alarm an den Inhaber.
  • PostgreSQL läuft mit einem synchronen Standby. Beide laufen auf derselben virtuellen Maschine.
  • Alle Plattform-Dienste laufen auf einem Server in einem Rechenzentrum. Einen zweiten Standort gibt es nicht.
  • Sicherungen: PostgreSQL jeden Sonntag vollständig und an den übrigen Tagen differenziell, mit WAL-Archiv für eine Wiederherstellung auf jeden Zeitpunkt der letzten 30 Tage; ClickHouse täglich; der Kubernetes-Datenspeicher alle sechs Stunden. Alarme melden veraltete Sicherungen.
  • Eine PostgreSQL-Sicherung bleibt, bis die nächste Vollsicherung älter als 30 Tage ist, höchstens 38 Tage. ClickHouse-Teile laufen nach höchstens 32 Tagen ab, die übrigen Sicherungen nach 30 Tagen.
  • Wiederherstellungsübungen mit Skript: Wiederherstellung von PostgreSQL auf einen Zeitpunkt und von ClickHouse am 22. Oktober 2026, Wiederherstellung aller Datenspeicher zuletzt am 2. November 2026, jeweils bestanden.
  • Cloudflare schützt die öffentlichen Adressen vor DDoS-Angriffen.

10. Löschung

  • Inhaber und Admins löschen eine Session mit allen Runs, Verläufen, Ereignissen und Artefakten. Die System-Sessions, die devboxes für Onboarding und Kalibrierung eines Projekts startet, können sie nicht löschen; sie laufen nicht ab und werden mit der Organization gelöscht.
  • Chat-Unterhaltungen und ihre Nachrichten bleiben, bis die Organization gelöscht wird. Löscht eine Person ihre Nachricht in Slack, Google Chat, Microsoft Teams oder Discord, löscht devboxes seine Kopie. Telegram meldet keine Löschung, daher behält devboxes seine Kopie einer Telegram-Nachricht.
  • Ein Inhaber löscht seine Organization, nachdem ihre Sessions gelöscht sind.
  • Ein Konto löscht devboxes auf Anfrage an privacy@devboxes.ai.
  • Gelöschte Daten bleiben bis zum Ablauf der Sicherungen erhalten, höchstens 38 Tage.
  • Traces in Langfuse laufen nach 30 Tagen ab. Medien, die Langfuse aus Traces auslagert, werden nicht gelöscht.
  • Fehlerberichte in Sentry laufen nach 90 Tagen ab.

11. Regelmäßige Überprüfung

  • Jede Änderung am Code wird vor dem Einsatz in Production geprüft.
  • Die Wiederherstellungsübungen aus Nr. 9 werden wiederholt und ihre Ergebnisse festgehalten.

12. Auftragskontrolle

  • devboxes setzt Unterauftragsverarbeiter mit einem Vertrag nach Art. 28 Abs. 4 DSGVO ein. Mit Monid und mit OpenAI für die System-Sessions steht er noch aus (Anlage 3).
  • devboxes ist ein Einzelunternehmen mit weniger als 20 Personen, die ständig mit der Verarbeitung personenbezogener Daten beschäftigt sind. Ein Datenschutzbeauftragter ist nach § 38 BDSG nicht zu benennen. Ansprechpartner ist der Inhaber unter privacy@devboxes.ai.

Anlage 3: Unterauftragsverarbeiter

Teil A: Unterauftragsverarbeiter von devboxes

  • Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Deutschland: Server für alle Dienste und für verwaltete Aufgaben, in Falkenstein, Deutschland. Vertrag zur Auftragsverarbeitung seit 28. Oktober 2026.
  • Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, USA: DNS, Proxy und DDoS-Schutz über das weltweite Netz von Cloudflare; Speicher für Session-Artefakte und verschlüsselte Sicherungen in R2 im Rechtsraum EU; Versand von E-Mails; lesender Betriebszugang. Grundlage: EU-US Data Privacy Framework, Standardvertragsklauseln als Rückfall.
  • Monid Inc, eine Kapitalgesellschaft nach dem Recht von Delaware, San Francisco, CA, USA: Websuche der Agenten in verwalteten Sessions, über deren Suchanbieter TinyFish, in den USA. Ein Vertrag mit Standardvertragsklauseln ist noch nicht geschlossen.
  • OpenAI Ireland Ltd, 1st Floor, The Liffey Trust Centre, 117-126 Sheriff Street Upper, Dublin 1, D01 YC43, Irland, Anbieter von ChatGPT im EWR, über ein ChatGPT-Konto von devboxes: das eigene Modell von devboxes für die System-Sessions, die das Repository eines neuen Projekts lesen, in den USA. Ein Vertrag mit Standardvertragsklauseln ist noch nicht geschlossen.
  • Google Cloud EMEA Ltd, Dublin, Irland, und Google LLC, USA: Zustellung der Google-Chat-Ereignisse über Pub/Sub, nur wenn die Organization Google Chat verbindet, in einer Google-Cloud-Region, die keine Speicherrichtlinie auf die EU beschränkt. Grundlage: EU-US Data Privacy Framework, Standardvertragsklauseln.

Teil B: Dienste, die der Kunde wählt

Diese Dienste sind keine Unterauftragsverarbeiter von devboxes (§ 5 Abs. 4). devboxes übermittelt ihnen Daten, wenn die Organization sie verbindet oder eine Person sie wählt:

  • der Modellanbieter, den die Organization verbindet
  • GitHub und GitLab für Repositories, GitHub und Google für die Anmeldung
  • Slack, Google Chat, Microsoft Teams, Linear, Jira, Discord und Telegram
  • Stripe (Link) als Verkäufer beim Kauf über Stripe Managed Payments
  • Exa, an das die Websuche eines Agenten auf einem Runner vom Rechner des Kunden aus geht