Datensicherheit in Archyl Cloud: was wir schützen, wie, und was wir nicht behaupten

Irgendwo in Ihrem Lieferantenfragebogen steht eine Zeile: „Werden Kundendaten im Ruhezustand verschlüsselt? Ja / Nein“. Für Archyl Cloud lautet die zutreffende Antwort „Ja, und zwar genau diese Felder“. Der Text Ihrer Architektur (Namen, Beschreibungen, ADRs, Dokumentation) und Ihre Zugangsdaten werden von unserer Anwendung verschlüsselt, bevor die Datenbank sie überhaupt zu sehen bekommt. Hochgeladene Dateien werden vom Speicheranbieter verschlüsselt. Identifikatoren, Zeitstempel, Diagrammpositionen und Konto-E-Mail-Adressen bleiben im Klartext, weil die Datenbank sie indexieren und joinen muss. Ein Anbieter, der „Ja“ ankreuzt, ohne zu sagen, was was ist, verlangt von Ihnen, den Rest des Fragebogens auf Treu und Glauben hinzunehmen.

Dieser Beitrag ist die ausführliche Antwort. Er behandelt, was wir verschlüsseln und wie, wie Daten fließen, wer worauf zugreifen kann, was unser KI-Anbieter erhält, wie wir testen und was Sie nach der DSGVO tun können. Er sagt auch klar, wo wir noch nicht sind: Archyl besitzt heute keine Sicherheitszertifizierung.

Alles hier stimmt mit dem Security Whitepaper (v3.0) und dem Auftragsverarbeitungsvertrag (DPA) überein, die beide am 27. September 2026 aktualisiert wurden und beide im Trust Center verlinkt sind. Falls sich ein Satz hier und ein Satz dort jemals widersprechen, sagen Sie es uns, denn einer von beiden ist falsch.

Die Kurzfassung

Für alle, die gerade ein Formular ausfüllen:

Der Rest des Beitrags liefert die Details hinter jeder Zeile.

Verschlüsselung im Ruhezustand, Feld für Feld

Archyl verschlüsselt Felder in der Anwendung, bevor sie in die Datenbank geschrieben werden. Jedes Modell, das Kundeninhalte enthält, besitzt einen Save-Hook, der seine Textfelder beim Schreiben mit AES-256-GCM verschlüsselt, und einen passenden Hook, der sie beim Lesen entschlüsselt. Jede Verschlüsselung verwendet eine frische zufällige Nonce, sodass derselbe Wert, zweimal gespeichert, zwei unterschiedliche Chiffretexte ergibt.

Das umfasst Ihre Architekturinhalte, nicht nur Ihre Secrets:

• C4-Modell: Systems, Containers, Components und Code-Elemente (Name, Beschreibung, Tags); Beziehungen (Beschreibung, Tags)
• Architecture Decision Records: Titel, Kontext, Entscheidung, Konsequenzen, Tags
• Dokumentation: Titel, Inhalt, Dateipfad, Tags; Kommentare dazu
• API-Verträge: Name, Beschreibung, Inhalt, Endpoint, Version
• Flows und Whiteboards: Namen, Beschreibungen, Technologie-Labels
• Außerdem: Overlays, Event-Channels, Insights, Releases, Konformitätsregeln, Änderungshistorie und Snapshots

Und alle Zugangsdaten und Secrets, die Archyl speichert:

• OAuth-Tokens von GitHub, GitLab und Bitbucket
• API-Schlüssel
• MFA-Secrets und Wiederherstellungscodes
• Zugangsdaten für Integrationen und den Marketplace
• Repository-Zugriffstokens
• Einstellungen für Cloud-Verbindungen

Das ist immer aktiv. Der Verschlüsselungsschlüssel wird mit Argon2id aus einem konfigurierten Secret abgeleitet, und der Server beendet sich beim Start, wenn dieses Secret fehlt oder kürzer als 32 Zeichen ist. Es gibt keine Konfiguration, in der Archyl läuft und diese Felder im Klartext schreibt.

Die praktische Konsequenz: Eine Kopie der Datenbank allein zeigt die Form Ihrer Daten, aber nicht ihre Worte. Die Namen Ihrer Services, die Begründungen in Ihren ADRs, der Inhalt Ihrer Docs, Ihr GitHub-Token und Ihr MFA-Secret erfordern alle zusätzlich den Schlüssel.

Zugangsdaten kommen außerdem nie wieder über die API heraus. Integrationseinstellungen werden bei jedem Lesezugriff geschwärzt: Sobald Sie einen Schlüssel in Archyl eingefügt haben, kann die Oberfläche Ihnen sagen, dass ein Schlüssel gespeichert ist, ihn Ihnen aber nicht erneut anzeigen, und kein API-Aufruf gibt ihn an irgendjemand anderen in Ihrer Organisation zurück.

Was das nicht abdeckt

Eine Datenbank muss Zeilen finden, sortieren und joinen können, und auf Chiffretext kann sie das nicht. Deshalb bleiben einige Felder im Klartext:

• Identifikatoren und die Verknüpfungen zwischen Elementen. Die Datenbank weiß, dass Element A zu Container B gehört und eine Beziehung zu Element C hat. Sie weiß nicht, wie irgendeines davon heißt.
• Zeitstempel und Diagrammpositionen.
• Konto-E-Mail-Adressen sowie Vor- und Nachnamen. Die E-Mail-Adresse hat einen eindeutigen Index, damit nicht zwei Konten dieselbe Adresse beanspruchen können.

Diese Felder sind durch die weiter unten beschriebenen Zugriffskontrollen und durch TLS bei der Übertragung geschützt. Dieser Beitrag trifft keine Aussage, weder in die eine noch in die andere Richtung, über eine Verschlüsselung der Datenbank auf Festplattenebene.

Hochgeladene Dateien

Dateien, die Sie an Dokumentation anhängen (Bilder, PDFs, andere Dokumente), liegen nicht in der Datenbank. Sie werden in Google Cloud Storage gespeichert, und:

• Buckets sind privat. Nichts darin ist öffentlich lesbar oder auflistbar.
• Dateien werden im Ruhezustand mit AES-256 verschlüsselt, durch Google Cloud Storage, mit vom Anbieter verwalteten Schlüsseln.
• Dateien werden nur über kurzlebige signierte URLs ausgeliefert. Jeder Link gewährt Zugriff auf eine einzige Datei und läuft kurz nach seiner Erzeugung ab, sodass ein in ein Ticket oder einen Chat kopierter Link nicht mehr funktioniert, statt zu einer dauerhaften öffentlichen URL zu werden.
• Die Standardregion ist die EU: Belgien, europe-west1.

Verschlüsselung bei der Übertragung

Der Datenverkehr zwischen Ihrem Browser, Ihren Tools und Archyl Cloud nutzt TLS 1.3. Die Verbindung der Anwendung zu ihrer PostgreSQL-Datenbank erfordert SSL, die Anwendung spricht also nicht im Klartext mit der Datenbank.

Wer hineinkommt

Menschen

• Multi-Faktor-Authentifizierung nutzt TOTP, die sechsstelligen Codes aus einer Authenticator-App. Jede MFA-Challenge kann nur einmal verwendet werden, und Wiederherstellungscodes werden als bcrypt-Hashes gespeichert, sodass sie geprüft, aber nicht zurückgelesen werden können.
• Single Sign-on unterstützt SAML 2.0 und OpenID Connect. Die Anmeldung beginnt immer bei Archyl (ausschließlich SP-initiated), und der State, der die Antwort Ihres Identity Providers an diese Anfrage bindet, ist an den Browser gebunden, der sie gestartet hat, und nur einmal gültig. Unser SSO-Beitrag beschreibt die Einrichtung.
• OAuth-Anmeldung ist mit GitHub, GitLab und Bitbucket verfügbar.
• Das Ändern Ihres Passworts oder das Entfernen der MFA widerruft alle älteren Sessions. Wenn Sie glauben, dass ein Passwort geleakt wurde, meldet eine Änderung jedes andere Gerät ab, das es verwendet hat.
• Das Zurücksetzen des Passworts verrät nicht, ob ein Konto existiert, und ein Reset-Link funktioniert nicht mehr, sobald er verwendet wurde.
• Anmeldung, MFA und Passwort-Reset sind rate-limitiert, mit gestaffelten Limits, sodass eine einzelne IP, ein einzelnes Konto oder eine einzelne Challenge jeweils nur begrenzt oft versucht werden kann.

Maschinen: API-Schlüssel und KI-Agenten

• API-Schlüssel sind standardmäßig schreibgeschützt. Schreibzugriff muss gewährt werden, und ein Schlüssel kann auf bestimmte Projekte beschränkt werden, sodass ein Schlüssel für einen CI-Job, der nur das Modell eines Projekts liest, genau das tun kann.
• Der MCP-Server, über den KI-Agenten Ihre Architektur lesen und aktualisieren, authentifiziert per OAuth mit verpflichtendem PKCE. Jede Mutation erfordert einen Schreib-Scope, sodass ein Agent, den Sie angebunden haben, um Fragen zu Ihrer Architektur zu beantworten, sie nicht ändern kann, es sei denn, Sie haben Schreibzugriff gewährt.

Mandantentrennung

Der Fehler, gegen den jedes mandantenfähige Produkt anarbeiten muss, ist schnell beschrieben: Der Server prüft, dass Sie angemeldet sind und zu irgendeiner Organisation gehören, und vertraut dann jedem Identifikator, der in der Anfrage steht. Ändern Sie die ID in der URL, und Sie lesen die Daten eines anderen.

Archyl autorisiert jede Anfrage gegen die Ressource, auf die sie zugreift. Wer ein Diagramm, ein Dokument oder einen Schlüssel anfragt, löst die Prüfung aus, ob das Projekt oder die Organisation, der genau diese Ressource gehört, eine ist, auf die Sie Zugriff haben, und nicht nur, ob Sie angemeldet sind. Dieselbe Regel gilt für die HTTP-API und für den MCP-Server.

Zwei Eigenschaften sorgen dafür, dass das auf Dauer hält:

• Die Autorisierung schlägt geschlossen fehl (fail closed). Wenn sich nicht feststellen lässt, wem eine Ressource gehört, lautet die Antwort nein.
• Automatisierte Mandanten-Tests laufen in der CI und lassen den Build fehlschlagen, wenn eine Autorisierungsprüfung entfernt wird, statt darauf zu warten, dass es jemandem auffällt.

Was die KI sieht

Die KI-Funktionen von Archyl Cloud nutzen OpenAI und keinen anderen KI-Anbieter, es sei denn, Ihre Organisation konfiguriert ihren eigenen Schlüssel.

Für die Architektur-Discovery, die ein Repository liest und ein C4-Modell vorschlägt, senden wir Code-Signaturen statt Quellcode. Hier ist eine Datei, so wie sie in Ihrem Repository liegt:

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

Und hier ist der Abschnitt, den Discovery daraus erstellt, also das, was in den Prompt gelangt:

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

Die Freigaberegel, der Schwellenwert und der Rumpf von Finalize bleiben draußen. Was hineingeht: der Repository-Name, die Datei- und Verzeichnisstruktur und diese Signaturen (Imports, Typ- und Funktionsdeklarationen, exportierte Konstanten). Das reicht, um zu erkennen, dass eine Billing-Component mit Stripe spricht. Es ist aber nicht nichts: Funktions- und Typnamen beschreiben Ihr System, behandeln Sie sie also als Daten, die Sie teilen.

Zwei Einschränkungen dieser Aussage, damit Sie nicht mehr hineinlesen, als sie sagt:

• Sie beschreibt, wie Discovery mit Quellcode umgeht. Findet Discovery im Repository in Markdown geschriebene Architecture Decision Records, sendet sie deren Text, um daraus strukturierte Entscheidungen zu machen, und sie sendet die ersten Zeilen von Dokumentationsdateien, um ihnen Titel zu geben.
• Andere KI-Funktionen senden, was ihre Aufgabe erfordert. Ein Coding-Agent zum Beispiel arbeitet an den Dateien, die er ändert, und sieht sie daher.

Wenn Ihre Richtlinie vorschreibt, dass Code nur an einen Anbieter gehen darf, mit dem Sie einen Vertrag haben, können Organisationen ihren eigenen KI-Schlüssel mitbringen. KI-Anfragen gehen dann an diesen Anbieter, unter Ihrem Vertrag. Wenn überhaupt nichts Ihr Netzwerk verlassen darf, kann ein selbst gehostetes Archyl Modelle mit Ollama auf Ihrer eigenen Hardware ausführen.

Wie wir das testen

In der Pipeline

Unsere CI-Pipeline führt vier Sicherheitsscanner aus:

• govulncheck für bekannte Schwachstellen in den Go-Abhängigkeiten, die wir tatsächlich aufrufen
• CodeQL für die statische Analyse unseres eigenen Codes
• gitleaks für versehentlich committete Secrets
• Trivy für Schwachstellen in Container-Images und Infrastrukturkonfiguration

In der Plattform

• Ausgehende Anfragen werden geprüft. Jede Integration, die eine von Ihnen angegebene URL aufruft (einen selbst gehosteten Git-Server, einen Webhook, einen KI-Endpoint), ist gegen Server-Side Request Forgery geschützt, sodass diese URL nicht dazu genutzt werden kann, Archyl sein eigenes internes Netzwerk erreichen zu lassen.
• Der Browser führt nur die Skripte aus, die wir ausliefern. Eine strikte Content-Security-Policy listet jedes Inline-Skript per Hash auf, und von einem CDN geladene Skripte tragen Subresource-Integrity-Hashes, sodass eine veränderte Kopie abgelehnt wird.
• Container sind abgeriegelt. Sie laufen als Nicht-Root-Benutzer, auf einem schreibgeschützten Dateisystem, ohne Linux-Capabilities.
• Sicherheitsereignisse werden protokolliert, darunter fehlgeschlagene Anmeldungen, fehlgeschlagene MFA-Versuche und abgelehnte Tokens.

Penetrationstests

Zwischen Juli und September 2026 haben wir zehn Runden interner Penetrationstests durchgeführt. Jeder Befund wurde behoben und durch einen Regressionstest abgedeckt, sodass dasselbe Problem erkannt wird, falls es zurückkehrt.

„Intern“ bedeutet genau das: Wir haben diese Tests selbst durchgeführt, und kein unabhängiges Unternehmen war beteiligt. Ein unabhängiger Penetrationstest ist im Rahmen des SOC-2-Audits geplant.

Ihre Rechte nach der DSGVO

• Export. Sie können Ihre Daten als JSON exportieren.
• Löschung. Das Löschen Ihres Kontos löscht alles, was dazu gehört, kaskadierend durch Ihre Daten und einschließlich hochgeladener Anhänge im Object Storage.
• Ein DPA für jeden Kunden. Der Auftragsverarbeitungsvertrag steht allen Kunden zur Verfügung.
• Meldung von Datenschutzverletzungen innerhalb von 72 Stunden.
• 30 Tage Vorankündigung vor jeder Änderung unserer Unterauftragsverarbeiter, damit Sie widersprechen können, bevor die Änderung erfolgt.

Das sind die heutigen Unterauftragsverarbeiter:

Der DPA nennt für jeden den Standort und die rechtlichen Garantien.

Was wir noch nicht behaupten

Eine Sicherheitsseite, die nur Stärken aufzählt, überlässt es Ihnen, die Lücken selbst zu finden. Hier sind sie:

• Keine Zertifizierung. Archyl ist nicht SOC-2-zertifiziert und nicht ISO-27001-zertifiziert. Für SOC 2 Type I ist das Readiness Assessment abgeschlossen und das unabhängige Audit ausstehend. ISO 27001 ist geplant. Sobald ein Auditbericht existiert, wird das Trust Center es sagen; bis dahin sollte nichts, was wir veröffentlichen, etwas anderes nahelegen.
• Noch kein unabhängiger Penetrationstest. Die oben beschriebenen zehn Runden waren intern. Der unabhängige Test kommt mit dem SOC-2-Audit.
• Nicht jede Spalte ist verschlüsselt. Identifikatoren, Zeitstempel, Diagrammpositionen, E-Mail-Adressen und Namen bleiben im Klartext, wie oben beschrieben.

Wenn Ihr Prozess eine Zertifizierung verlangt, die Archyl noch nicht hat, ist das eine echte Einschränkung, und wir möchten lieber, dass Sie es jetzt erfahren als in Woche sechs einer Einkaufsprüfung.

Wie es weitergeht

• Das Trust Center bündelt die Dokumente an einem Ort.
• Das Security Whitepaper geht tiefer auf jede Kontrolle ein, einschließlich der Rate Limits und der Sicherheitsereignisse, die wir protokollieren.
• Der Auftragsverarbeitungsvertrag ist die vertragliche Fassung des DSGVO-Abschnitts oben.
• Für Datenschutzfragen oder Fragebogenpunkte, die dieser Beitrag nicht beantwortet, schreiben Sie an privacy@archyl.com.
• Um eine Schwachstelle zu melden, schreiben Sie an security@archyl.com. Wir bestätigen den Eingang innerhalb von 24 Stunden.

Wenn Sie derjenige sind, der Archyl freigeben muss, möchten wir lieber, dass Sie auf jede Frage eine präzise Antwort finden als auf die meisten eine selbstbewusste. Wo etwas hier für Ihre Prüfung nicht präzise genug ist, fragen Sie nach, und wir machen es präzise.