AI-BOUNDARY-2.0 · 2026-11-02
Die immo.quick Serverless Edition prüft den geschützten Ausführungsweg unmittelbar vor dem ersten Befehl der aufgerufenen Funktion. Diese Grenze gilt für menschliche Aufrufe ebenso wie für Aufrufe durch Funktionen und Workflows. Ein KI-Agent erhält dadurch kein Ausführungsrecht. Der folgende Stand wurde am 2. November 2026 vom Herausgeber als intern geprüft gemeldet.
Die Übersicht bezieht ihren Zustand aus Prüfungen der Laufzeit: Integritätssiegel und Audit-Kette, Kryptoverfahren, freigegebene Verbindungsziele, Anmeldungen und Sitzungen, Schlüsselherkunft ohne Schlüsselwerte, Laufzeitrechte und KI-Grenze. Eine Momentaufnahme kann mit einem Receipt festgehalten werden.
Jeder Bearbeitungsschritt wird mit Receipt erfasst. Das System berechnet die hinterlegten Meldefristen und dokumentiert Behörde und Aktenzeichen. Die Meldung übernimmt ein Mensch. Ein Vorfall kann erst abgeschlossen werden, wenn die erforderlichen Meldungen festgehalten sind. Die rechtlichen Fristanker und Anwendungsgrenzen stehen unterhalb der Karten.
Ein Administrator kann alle Sitzungen eines Kontos gemeinsam beenden. Die Sitzungen des Eigentümers kann ausschließlich der Eigentümer beenden. Sitzungswiderruf bleibt eine eigenständige Zugriffskontrolle.
Jede KI-Nutzung muss registriert sein. Nicht registrierte Nutzung wird abgewiesen. Urteile und Freigaben werden aus KI-Antworten entfernt. Eine KI-Antwort begründet weder eine fachliche Freigabe noch ein Ausführungsrecht.
KI hat im System nie ein Ausführungsrecht. Deshalb gibt es keinen KI-Not-Aus als Systemfunktion. Unmittelbar vor dem ersten Befehl einer Funktion des geschützten Ausführungswegs prüft die Laufzeit die Eingabe. Ein KI-Agent als Aufrufer oder KI-Herkunft ohne menschliche Bestätigung für genau diese Funktion führt zur Abweisung. Der abgewiesene Auftrag wird nicht ausgeführt. Die Abweisung erhält ein Receipt mit BLOCK, Funktionsbezug und dem Vermerk „nichts ausgeführt“. Eine menschliche Bestätigung ersetzt keine sonstigen Autoritäts- oder Ausführungsprüfungen.
Vorschläge eines KI-Agenten haben keine unmittelbare Wirkung. Der Agent darf keine Ausführungsfunktion aufrufen, keine Datenänderung auslösen und keine Freigabe erteilen. Er wird nie Administrator. Ausschließlich der Eigentümer darf ein Konto als KI-Agent kennzeichnen.
Die gemeldete Software-Stückliste umfasst 746 Bausteine. Jeder ist mit einer festen Version und einer Prüfsumme erfasst. Diese Bestandsangabe ist versionsgebunden und keine externe Sicherheitszertifizierung.
Der Herausgeber meldet eine vollständig grüne interne Testsuite und 46 Prüfungen der KI-Leitplanken, einschließlich Angriffstests. In den Abweisungstests wurde keine Datensatzschreibung durch den abgewiesenen Ausführungsweg beobachtet. Das Abweisungsreceipt dokumentiert diese Grenze; es ist keine Ausführungserlaubnis. Ein externer Penetrationstest wurde noch nicht durchgeführt. Interne Tests ersetzen weder einen solchen Test noch eine Zertifizierung.
Anmeldung: Der zweite Faktor ist im gemeldeten Stand auf Entscheidung des Eigentümers deaktiviert. Dies ist eine dokumentierte Betriebseinstellung, keine Aussage zur Erfüllung institutioneller Authentifizierungsanforderungen.
Für erhebliche Sicherheitsvorfälle grundsätzlich Frühwarnung innerhalb von 24 Stunden und Vorfallsmeldung innerhalb von 72 Stunden nach Kenntniserlangung. Abschlussbericht spätestens einen Monat nach der Vorfallsmeldung. Für fortdauernde Vorfälle und Vertrauensdienste gelten besondere Regeln; maßgeblich ist die anwendbare nationale Umsetzung.
EUR-Lex · NIS2 · Artikel 23Erstmeldung so früh wie möglich, spätestens vier Stunden nach Einstufung als schwerwiegender IKT-Vorfall und grundsätzlich spätestens 24 Stunden nach Kenntniserlangung. Erfolgt die Einstufung erst nach diesen 24 Stunden, gilt die Vierstundenfrist ab Einstufung. Die gesetzlichen Folgefristen sind gesondert zu beachten.
EUR-Lex · DORA · Delegierte Verordnung (EU) 2025/301, Artikel 5Eine meldepflichtige Verletzung personenbezogener Daten ist unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden zu melden. Die Ausnahme für voraussichtlich fehlendes Risiko sowie die Begründung einer verspäteten Meldung bleiben maßgeblich.
EUR-Lex · DSGVO · Artikel 33Cyber-Sicherheit · Serverless Edition™
Wer die Serverless Edition über ihre eigene API anbindet, bekommt den Schutz automatisch mit. Kein Zusatzmodul, keine Sicherheitsstufe gegen Aufpreis. Jede Anfrage läuft durch dieselben Schutzschichten, jede Prüfung endet in einem signierten Receipt, und jeder Fehler wird sichtbar gemeldet statt verschluckt.
IN BETRIEB
Die institutionelle API ist ein eigenes Maschinenprotokoll. Ein Maschinenzugang wird nie als Administrator-Sitzung behandelt. Abgelehnte Anfragen werden protokolliert, wiederholte Fehlversuche je Absender begrenzt.
IN BETRIEB
Jede Anfrage hat eine feste Größengrenze, institutionelle Anfragen höchstens 16 KB. Zu langsame Übertragungen werden abgebrochen. Das schützt vor Überlastung durch übergroße oder künstlich verzögerte Anfragen.
IN BETRIEB
Das System verbindet sich nur mit Zielen, die im versiegelten Code oder in der Konfiguration stehen. Interne und private Netze sind gesperrt, jede Weiterleitung wird einzeln geprüft, jede Sperre protokolliert. Das verhindert Angriffe, die das System als Sprungbrett nutzen wollen (SSRF).
IN BETRIEB
Beim Start prüft das System jede Programmdatei gegen ein versiegeltes Verzeichnis. Im Durchsetzungsmodus verweigert es bei einer Abweichung den Start, statt mit verändertem Code weiterzulaufen.
IN BETRIEB
Wo keine Regel steht, hat nur ein Administrator Zugriff. Die Regelregister selbst sind für direkte Änderungen gesperrt, auch für Administratoren. Änderungen laufen nur über drei Freigaben verschiedener Personen.
IN BETRIEB
Fehlgeschlagene Anmeldeversuche werden gezählt und begrenzt. Sitzungen laufen nach fester Zeit ab.
IN BETRIEB
Sicherheitsrelevante Vorgänge landen in einem Audit-Protokoll, das nur ergänzt werden kann und als Hash-Kette verbunden ist. Eine nachträgliche Änderung fällt auf.
IN BETRIEB
Jede Prüfung endet in einem Receipt mit Ed25519 und ML-DSA-87, verkettet mit SHA-384. Die Tageswurzel trägt zusätzlich SLH-DSA-SHA2-256s. Ein Receipt gilt nur, wenn beide Signaturen stimmen.
IN BETRIEB
Wird ein Verfahren als kompromittiert markiert, stellt das System damit sofort nichts mehr aus. Stattdessen gibt es einen technischen Abbruch mit Fehlerdatensatz und Alarm.
IN BETRIEB
Schlüssel werden mit X25519 und ML-KEM-1024 (FIPS 203) ausgetauscht, gegen heutige und künftige Angriffe.
IN BETRIEB
Jede Nacht prüft das System seine Nachweisketten. Bricht eine Kette, entsteht für jeden betroffenen Datensatz ein kritischer Alarm, bevor Aufbewahrungsfristen greifen.
IN BETRIEB
Signaturschlüssel werden lokal erzeugt, nie angezeigt und nie übertragen. Fehlen sie, stellt das System kein Receipt aus.
IN BETRIEB: läuft im aktuellen Systemstand. EINGEBAUT · AKTIV NACH EINRICHTUNG: vorhanden und geprüft, wird mit Ihrer Konfiguration aktiv.
IN BETRIEB
Ein Sicherheitsvorfall wird mit einem forensischen Receipt erfasst und intern an das Sicherheitsteam gemeldet. Die offizielle Meldung an das BSI erfolgt über dessen Meldeformular; das Receipt ist der Beleg dafür.
IN BETRIEB
Das System bereitet Meldungen nach DORA (Erstmeldung binnen 4 Stunden) und NIS2 (binnen 24 Stunden) vor. Jedes Feld stammt aus signierten Systemdaten. Was noch nicht feststeht, wird als „noch nicht festgestellt“ ausgewiesen, nie geschätzt.
IN BETRIEB
Warnt oder blockiert die Prüfung nach dem Cyber Resilience Act, erstellt das System über eine eigens freigegebene Dienstidentität automatisch den Meldeentwurf, je Vorfall genau einmal.
EINGEBAUT · AKTIV NACH EINRICHTUNG
Sicherheitsereignisse gehen im Common Event Format (CEF) an Ihr SIEM, sobald dessen Adresse eingetragen ist.
IN BETRIEB
Externe Hinweise auf Schwachstellen werden über einen festen Weg angenommen und mit Receipt bestätigt.
Dieselbe API prüft auch Ihre Pflichten. Jede Prüfung endet in einem eigenen Receipt.
gateNIS2
gateDORA
gateCRA
gateCER
gateTechStandards
gateAIHighRiskConformity
gateDataAct
gateEUDPF