Cloud & KI für regulierte Unternehmen — vom Team hinter Redactor. · Das ganze Portfolio →
Sicherheit & Transparenz

Vertrauen Sie uns nicht. Prüfen Sie das Design.

Der Sicherheitsanspruch von Redactor Desk ist strukturell, keine Richtlinien-Zusage: Kein Werkzeug des Agenten kann unbereinigt hinausschreiben. Diese Seite erklärt, wie das gebaut ist und wo die ehrlichen Grenzen liegen. Sie ist von unseren Entwicklern geschrieben — kein Audit durch Dritte (ein unabhängiges Audit steht auf der Roadmap).

Die Kern-Invariante

Zwei Sätze, an denen alles hängt.

  • Alles, was in den Modell-Kontext gelangt — Datei-Inhalte, Suchergebnisse, Ihre eigene Nachricht — läuft zuerst durch sanitize().
  • Alles, was das Modell ausgibt — Chat-Text, geschriebene Datei-Inhalte, Änderungen — läuft durch die Wiederherstellung, bevor es angezeigt oder auf die Festplatte geschrieben wird.

Warum hier nichts leaken kann

Ein einziger Kontrollpunkt

Detektion und Tokenisierung laufen ausschließlich lokal. Es gibt genau eine Stelle, an der Text zum Modell wird — und sie redigiert.

Keine Shell, keine Built-ins

Der Agent hat keinen Shell-Zugriff und keine eingebauten Werkzeuge. Nur fünf Dateioperationen sind erlaubt, jede über die Redaktionsschicht. Kein Kanal führt daran vorbei.

Bearbeitung im bereinigten Raum

Das Modell bearbeitet die geschwärzte Sicht; die echten Werte werden erst lokal wieder eingesetzt, kurz bevor die Datei geschrieben wird. Ein Hash-Wächter weist veraltete Änderungen ab.

Fail closed — im Zweifel zu

Wo eine Kategorie auf „blockieren" gesetzt ist (Enterprise-Richtlinie), gibt die Redaktionsschicht im Zweifel nichts heraus, statt etwas durchzulassen.

Was ein Pack nicht kann

Ein Pack bringt fremden Text in den Kontext Ihres Agenten. Das ist ein berechtigter Einwand — und der Grund, warum das Format bewusst arm gehalten ist.

  • Ein Pack ist ein Verzeichnis aus einer Manifest-Datei und Markdown-Texten. Es kann kein Werkzeug definieren, keine Netzwerkverbindung öffnen, keine Datei lesen und kein Skript starten. Es kann die Werkzeug-Freigabe nicht verändern, eine Sitzung nicht vom Plan- in den Build-Modus schalten und nicht bestimmen, welche Erkennungs-Kategorien blockiert sind. Das ist eine Eigenschaft des Formats, keine Zusage über gutes Benehmen.
  • Geprüft wird jedes Pack, auch unser eigenes. Beim Laden vergleicht der Client den Inhalt mit dem, was das Manifest anmeldet — in beide Richtungen. Ein Pack, das mehr mitbringt als angemeldet, wird abgewiesen; ein Pack, das eine Fähigkeit anmeldet, für die es keinen Inhalt hat, ebenfalls. Abgewiesen heißt sichtbar: in der Packs-Ansicht, mit Grund, statt still übersprungen.
  • Die Zusicherung steht nicht nur im Text — sie läuft als Test. Die Prüffälle liegen als Korpus im Pack-Repository: je ein Pack-Verzeichnis und das Urteil, das es erzeugen muss. Der Client führt denselben Korpus in seinen Tests aus. Bricht die Regel „ein Pack, dessen Inhalt sein Manifest übersteigt, wird abgewiesen", so bricht sie an beiden Stellen zugleich — zwei Prosatexte, die stillschweigend auseinanderlaufen, gibt es nicht.
  • Erkennungsregeln aus Packs sind noch nicht in Betrieb. Ein Pack darf Detektoren und Hinweise mitbringen; der Client validiert sie, wendet sie aber in keiner ausgelieferten Fassung an. Ein Pack kann die Erkennung heute also weder erweitern noch schwächen.
  • Nichts wird nachgeladen, nichts gemeldet. Der Client holt keine Packs aus einem Katalog und meldet nirgendwohin, welche Sie aktiviert haben. Ein eigenes Pack legen Sie selbst in einen Ordner; es bleibt auf Ihrem Rechner.
Zur Lizenzdatei im Programmpaket: Neben der mitgelieferten Kopie der Packs liegt eine Apache-2.0-Lizenzdatei — wer sie dort findet, könnte den Eindruck gewinnen, das Programm selbst sei Open Source. Ist es nicht. Die Lizenz gilt ausschließlich für die Pack-Inhalte, also für die Texte. Redactor Desk und die Redaktions-Engine sind proprietär (geschlossener Quelltext) und bleiben es. Den Wortlaut der Packs finden Sie unter github.com/ZDF-OSS/redactor-packs.

Ihre Daten

  • Der Anthropic-Key wird verschlüsselt über den OS-Schlüsselbund gespeichert (Keychain/DPAPI), nie im Klartext. Bei Amazon Bedrock bevorzugt der Client Ihre IAM-Credential-Chain (SSO, temporäre Credentials) — statische AWS-Schlüssel sind nur der Fallback und werden genauso verschlüsselt abgelegt.
  • Die Zuordnung Platzhalter → echter Wert liegt in einem lokalen Tresor auf Ihrem Rechner. Nichts davon verlässt das Gerät.
  • Das Nachweis-Protokoll (Enterprise, optional) ist hash-verkettet und enthält nur Kategorien und Zähler — nie die Werte selbst.
  • Vor jeder Datei-Änderung wird ein Backup angelegt; jede Änderung ist umkehrbar.

Ehrliche Grenzen

  • Erkennung ist deterministisch-heuristisch. Was nicht erkannt wird, wird nicht ersetzt — wir versprechen keine Trefferquoten ohne unabhängigen Benchmark.
  • „Vollständig offline" gilt für Erkennung und Tokenisierung. Der Client selbst spricht mit der Modell-API — der Anthropic-API oder Ihrem eigenen Amazon Bedrock in der EU-Region, innerhalb Ihrer AWS-Grenze, mit Ihrem IAM.
  • Regulatorik-Formulierungen sind bewusst „unterstützt", nie „erfüllt".
Seit 0.3.0 ausgeliefert: die Ausgangsprüfung — ein lokaler Egress-Wächter, der vor jedem Senden den bereits bereinigten Text noch einmal auf Tresor-Werte und bekannte Secret-Muster prüft. Sie ist bewusst als warnende Kontrolle ausgelegt: Sie meldet und protokolliert den Fund, sie hält den Request nicht auf. Weiter auf der Roadmap: Tresor-Verschlüsselung at rest und ein unabhängiges Audit. Sobald der Bericht vorliegt, veröffentlichen wir ihn hier.

Sicherheitslücke melden

Sie haben etwas gefunden? Melden Sie es bitte vertraulich und geben Sie uns angemessene Zeit zur Behebung. Bitte keine echten Secrets in der Meldung.