Control iso27001:A.5.1 im Compliance-Register; unterstützt auch Klausel 5 (Führung), iso27001:A.6.7 (Remote-Arbeit) und iso27001:A.8.24 (Kryptografie).
Festgelegt durch den Eigentümer am 2-10-2026. Zugleich akzeptierte der Eigentümer die Restrisiken, die das Risikoregister als „akzeptiert" behandelt, darunter eine einzige Person als Eigentümer und Administrator sowie das Fehlen eines externen Penetrationstests.
Dies ist die Richtlinie, die ISO 27001 A.5.1 verlangt: ein einziges Dokument, in dem steht, was Stilops im Bereich Informationssicherheit erreichen will, wer worüber entscheidet und welche Regeln gelten. Sie ist bewusst kurz gehalten und beschreibt, was tatsächlich geschieht. Eine Richtlinie, die schöner ist als die Praxis, ist keine Richtlinie, sondern ein Wunsch.
1. Zweck und Geltungsbereich
Stilops liefert KI-Agenten, die im Namen einer Organisation Arbeit ausführen. Kunden vertrauen uns dabei ihre Geschäftsdaten an, und mitunter personenbezogene Daten ihrer Kontakte. Der Kern des Produkts ist nicht nur, dass die Arbeit erledigt wird, sondern dass sich im Nachhinein nachvollziehen lässt, was geschehen ist und wer es genehmigt hat.
Diese Richtlinie gilt für die gesamte Plattform: das Kundenportal, die Verwaltungsumgebung, die öffentliche Website, die Ausführung von Agenten-Aufgaben und die Infrastruktur, auf der dies läuft. Sie gilt für jeden, der daran arbeitet – derzeit der Eigentümer – und für die Agenten, die selbst in der Codebasis arbeiten.
2. Ziele
- Vertraulichkeit. Daten einer Organisation sind für eine andere Organisation nicht zugänglich, und Geheimnisse angebundener Systeme werden verschlüsselt gespeichert und einem Agenten nicht angezeigt. Wo ein Agent ein Geheimnis technisch benötigt, erhält er es nur für die Dauer dieser Aufgabe; die Ausnahmen stehen unter „Kryptografie und Schlüsselverwaltung" und in §5.
- Integrität und Nachvollziehbarkeit. Was ein Agent vorschlug, wer es genehmigte und was das Ergebnis war, ist festgehalten und wird nachträglich nicht geändert.
- Verfügbarkeit. Der Dienst läuft, und eine Störung ist ohne Verlust des Prüfpfads behebbar.
- Menschliche Entscheidungshoheit. Keine Wirkung ohne einen Menschen, der sie genehmigt hat.
Das vierte Ziel ist bei Stilops keine Sicherheitsmaßnahme, sondern der Ausgangspunkt des Produkts. Die anderen drei dienen dazu, dieses vierte glaubwürdig zu machen.
3. Wer entscheidet was
| Gegenstand | Wer |
|---|---|
| Richtlinie festlegen und ändern | Der Eigentümer |
| Sicherheitsbewertung, Bedrohungsinformationen, Vorfallanalyse | Die CISO-Rolle |
| Alles, was eine gesetzliche Verpflichtung berührt oder zu einer öffentlichen Aussage wird | Der Eigentümer, stets – dies ist nicht delegierbar und nicht per Mandat auszuschalten |
| Technische Umsetzung, Änderungen an der Software | Die Entwicklungsrollen, über das feste Qualitätstor |
| Zuweisung von Befugnissen an einen Agenten | Der Eigentümer |
Dass der Eigentümer der einzige Mensch in dieser Tabelle ist, ist eine Tatsache und kein zu verbergender Mangel – aber es ist durchaus das größte Einzelrisiko im Risikoregister, und dort ist es auch als solches aufgeführt.
4. Geltende Regeln
Zugang. Der Zugang erfolgt personen- und rollenbezogen. Passwörter werden als starker, gesalzener Hash gespeichert. Die Zwei-Faktor-Authentifizierung steht jedem Nutzer zur Verfügung und ist als zusätzlicher Schritt bei Handlungen mit Folgen verpflichtend – darunter die öffentliche Bestätigung einer Compliance-Aussage. Für Logins und Formulare gilt ein Ratenlimit.
Arbeitsplatz und Remote-Arbeit. Stilops hat kein Büro; die gesamte Verwaltung erfolgt aus der Ferne, vom Arbeitsplatz des Eigentümers aus. Hierfür gelten diese Regeln: Der Datenträger des Geräts ist verschlüsselt, und der Bildschirm sperrt sich nach kurzer Inaktivität automatisch; Betriebssystem und Browser erhalten Sicherheitsupdates, sobald sie erscheinen; die Konten bei den Anbietern für Code, Hosting, DNS und Zahlungen sind durch Zwei-Faktor-Authentifizierung gesichert; der Zugang zu Servern erfolgt ausschließlich über SSH-Schlüssel, nicht über Passwörter; Produktionsdaten werden nicht auf den Arbeitsplatz kopiert, außer einer temporären Kopie für eine Wiederherstellung oder eine Untersuchung, die anschließend gelöscht wird. Bei Verlust oder Diebstahl des Geräts werden innerhalb von 24 Stunden die Sitzungen beendet und die darauf befindlichen Schlüssel erneuert, und es wird beurteilt, ob es sich um eine Datenschutzverletzung handelt, gemäß dem Verfahren für Vorfälle und Datenschutzverletzungen („Incident- en datalekprocedure").
Geheimnisse. Geheimnisse angebundener Systeme und der Infrastruktur werden verschlüsselt gespeichert (AES-256-GCM) mit einem Schlüssel pro Umgebung und erst in dem Moment entschlüsselt, in dem eine Aufgabe sie benötigt. Sie gelangen nie in den Auftrag an das Sprachmodell. Das versehentliche Mit-Committen eines Geheimnisses wird nur teilweise verhindert: Eine Prüfung im Qualitätstor durchsucht den Code nach Geheimnissen mit einem festen Präfix (wie GitHub-, Anthropic- und Stripe-Schlüssel sowie private Schlüssel), und dieselben Muster werden auf das angewendet, was Agenten als Änderung einreichen. Ein Geheimnis ohne erkennbares Präfix, wie ein Hetzner-Token oder ein Passwort, erfasst diese Kontrolle nicht. Ein Nutzer, der ein Geheimnis in eine Chatnachricht einfügt, dessen Nachricht wird abgefangen, bevor das Modell sie sieht.
Ausführung von Agenten-Aufgaben. Eine Agenten-Aufgabe läuft abgeschottet unter einem eigenen, eingeschränkten Konto aus einem festen Pool. Gibt es mehr gleichzeitige Aufgaben, als der Pool groß ist, so läuft eine Aufgabe vorläufig unter dem gemeinsamen Agenten-Konto, wo eine andere gleichzeitige Aufgabe ihre entschlüsselte Konfiguration lesen kann. Dies wird behoben. Ein Agent eines Kunden erhält niemals Zugriff auf Daten einer anderen Organisation, hat keine Mailbox und versendet keine E-Mails.
Änderungen an der Software. Jede Änderung durchläuft ein festes automatisiertes Tor: Stil, Typprüfung, die vollständige Testsuite, eine Prüfung auf mit-committete Geheimnisse und eine Prüfung auf bekannte Schwachstellen in Abhängigkeiten. Eine Änderung an einem Tor oder einer Befugnis muss darüber hinaus absichtlich gebrochen werden, um zu beweisen, dass der zugehörige Test rot wird – ein Tor, das nicht gebrochen wurde, bewacht nichts, bis das Gegenteil nachgewiesen ist.
Änderungen und Compliance. Jede Änderung wird vor der Zusammenführung auch daraufhin geprüft, was sie für die Compliance bedeutet: Berührt sie etwas, was ein Compliance-Dokument, die Controls oder die Bedingungen versprechen? Software bestimmt, welche Themen eine Änderung berührt; ein separater, nur lesender Prüfagent beurteilt dann, ob die Änderung so durchgehen darf, ob ein Compliance-Dokument mitgeändert werden muss (was Stilops selbst in derselben Änderung aktualisiert, woraufhin der Eigentümer den neuen Text festlegt), ob der Eigentümer entscheiden muss oder ob die Änderung zurückgehalten wird. Eine Änderung an den Bedingungen, der Datenschutzerklärung, dem Auftragsverarbeitungsvertrag oder der Liste der Unterauftragsverarbeiter, ein Risiko, das akzeptiert werden muss, und eine Maßnahme, die abgeschwächt wird, liegen stets beim Eigentümer; eine Prüfung, die zu keinem Urteil kommt, ebenfalls. Darüber hinaus legt Stilops jedes Quartal alle Compliance-Dokumente neben den Code und macht aus jeder Abweichung eine Feststellung.
Protokollierung. Handlungen von Administratoren und von Organisationsnutzern werden append-only protokolliert. Eine protokollierte Handlung wird nicht geändert und nicht gelöscht.
Kryptografie und Schlüsselverwaltung. Der Datenverkehr läuft über TLS. Ruhende Daten, die ein Geheimnis darstellen, sind mit AES-256-GCM verschlüsselt, mit zwei bekannten Ausnahmen: Das kurzlebige Lese-Token der Search-Console-Anbindung (höchstens eine Stunde gültig) liegt bewusst unverschlüsselt vor, und der Anthropic-API- Schlüssel für Kundenläufe liegt während eines solchen Laufs, bis zu zwei Minuten, als Datei auf dem Datenträger. Der Schlüssel liegt pro Umgebung außerhalb des Quellcodes und der Datenbank und ist nur für den Dienst selbst lesbar, auf Maschinen, auf denen die Agenten unter einem separaten Konto laufen (eine gesonderte Einstellung für dieses Konto). Wo diese Trennung nicht eingerichtet ist, wie in der lokalen Entwicklungs- und Produktionsumgebung, laufen Agenten als derselbe Benutzer wie der Dienst und können sowohl den Schlüssel als auch die verschlüsselten Werte lesen.
Was ein Agent lesen kann, auch dort, wo die Trennung eingerichtet ist: den Anthropic-API-Schlüssel während eines Kundenlaufs; das gewöhnliche Cloudflare-Token; solange der lokale Tunnel für Geheimnisse von Anbindungen nicht aktiv ist, die entschlüsselte Konfigurationsdatei einer Aufgabe; und bei vollem Pool auch die Konfigurationsdatei einer anderen gleichzeitigen Aufgabe, mit den Anbindungsgeheimnissen eines Kunden. Wo dieser Tunnel aktiv ist, gelangen diese Geheimnisse nicht in eine lesbare Datei. Auch die Datenbank mit den Daten aller Organisationen ist für das Agenten-Konto lesbar, weil die Server, die Agenten nutzen, sie benötigen. Ein Agent eines Kunden kommt nicht an sie heran: Er hat dann keine Shell, eine feste Kontrolle vor jeder Handlung beschränkt sein Lesen auf sein eigenes Arbeitsverzeichnis und seine Anhänge, und die Werkzeuge, die er erhält, filtern nach seiner Organisation. Diese Trennung liegt in der Anwendung, nicht im Betriebssystem: Fällt diese Kontrolle weg, hält das Konto nichts auf. Dies sind Restrisiken, und das erste steht im Risikoregister (R13).
Externe Zugriffsschlüssel werden erneuert, soweit der Anbieter dies zulässt. Das Cloudflare-Token erneuert Stilops selbst. Für Hetzner, GitHub, Anthropic, Stripe und MXroute erstellt Stilops eine Erinnerung als Feststellung, und der Eigentümer erneuert den Schlüssel selbst. Für die übrigen Anbindungen (S3, OneDrive, VirusTotal, LinkedIn, PageSpeed, Bing, das Google-Dienstkonto und die SMTP- und IMAP- Passwörter) steht keine Erinnerung bereit; dort gilt nur die manuelle Schlüsselrotation in der operativen Planung. Für Hetzner kommt eine Überwachung hinzu, die jede Handlung im Aktionsprotokoll von Hetzner meldet, die nicht von Stilops selbst stammt; für die anderen Anbieter besteht diese Überwachung nicht.
Ein Schlüsselwechsel nach einem (vermuteten) Leck macht bestehende öffentliche Compliance-Bestätigungen ungültig: diese müssen dann erneut abgegeben werden, denn wer den alten Schlüssel hatte, kann sie gefälscht haben. Bei einem gewöhnlichen Wechsel signiert Stilops jede Bestätigung, die mit dem alten Schlüssel stimmte, mit dem neuen Schlüssel neu. Sitzungen sowie Einladungs- und Reset-Links verfallen bei jedem Wechsel.
Vorfälle. Was ein Vorfall ist, wie er eingeht und innerhalb welcher Frist was an wen gemeldet wird, steht im Verfahren für Vorfälle und Datenschutzverletzungen („Incident- en datalekprocedure"). Die Entscheidung zur Meldung ist menschlich.
Lieferanten. Jede Partei, die personenbezogene Daten verarbeitet, steht mit Namen, Zweck, Land und dem Stand der Auftragsverarbeitungsvereinbarung in der Liste der Unterauftragsverarbeiter („Subverwerkerslijst") – auch dort, wo diese Vereinbarung fehlt.
5. Was diese Richtlinie ehrlich eingestehen muss
- Es gibt keine Funktionstrennung. Eine Person legt die Richtlinie fest, genehmigt und administriert. Die Kompensation besteht darin, dass der Prüfpfad vollständig und append-only ist und dass die schwersten Handlungen einen zusätzlichen Verifizierungsschritt erfordern. Das ist eine Kompensation, keine Lösung.
- Die Wiederherstellung wird erprobt, aber noch nicht vollständig. Das Entschlüsseln und Überprüfen der Backups ist getestet; eine vollständige Wiederherstellungsübung pro Quartal ist eingerichtet, und die erste Durchführung steht noch aus. Details stehen im Kontinuitätsplan, den Kunden im Portal einsehen können.
- Geheimnisse sind nicht für jeden Agenten unlesbar. Siehe „Kryptografie und Schlüsselverwaltung": der Anthropic-API-Schlüssel während eines Kundenlaufs, das gewöhnliche Cloudflare-Token und, auf Maschinen ohne getrenntes Agentenkonto, auch der Schlüssel selbst. Das Abdichten dieser Punkte ist eine offene Abwägung.
- Die Trennung zwischen Organisationen in der Datenbank ist eine Trennung in der Anwendung. Die Datenbank mit den Daten aller Organisationen ist für das Agenten-Konto lesbar, weil die Server, die Agenten nutzen, sie benötigen. Dass ein Agent eines Kunden nicht an sie herankommt, regelt eine feste Kontrolle in der Anwendung, nicht das Betriebssystem: Fällt diese Kontrolle weg, hält das Konto nichts auf.
- Es gibt keinen externen Penetrationstest.
Diese Punkte stehen als offener Punkt im Compliance-Register. Sie stehen hier, weil eine Sicherheitsrichtlinie, die nur die Stärken nennt, den Leser darüber täuscht, worauf er sich verlassen kann.
6. Einhaltung und Überprüfung
Das Compliance-Register unter stilops.com/nalevingsregister ist die laufende Messung dieser Richtlinie: pro Norm und pro Control der Stand, mit Nachweis. Abweichungen gehen als Feststellung ein und werden an die zuständige Stelle weitergeleitet.
Diese Richtlinie wird überprüft, wenn die Organisation auf mehr als eine Person wächst, wenn eine neue Kategorie von Daten oder ein neuer Lieferant hinzukommt, nach einem Vorfall mit Auswirkung und spätestens jährlich.