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 33Neu: Welche Cyber-Schutzmechanismen automatisch greifen, sobald die Serverless Edition über ihre API angebunden ist: Cyber-Sicherheit per API →
immo.quick trennt Zugang von Ausführungsautorität. Eine Anfrage muss zuerst die jeweilige Eintrittsgrenze passieren; selbst erfolgreicher Zugang autorisiert noch keinen produktiven Effekt.
Core™ setzt einen fail-closed Access Guardian vor die Governance- und Compliance-Pipeline. Scheitert eine erforderliche Validierungsbedingung, erreicht die Anfrage die nachgelagerte Governance-Logik nicht.
Die Serverless Edition™ verlangt bereits am Edge eine gültige Attestation eines registrierten Clients, bevor die Anfrage den nachgelagerten Gate-Pfad erreicht.
Zugang ist keine Autorität. Ein produktiver Effekt erfordert ein gültiges, aktuelles und scope-gebundenes Execution Right sowie eine ausführbare Capability.
Claim Boundary: Ausschließlich die Architektur der immo.quick Serverless Edition™ wurde dem BSI am 28.07.2026 nachweislich vorgelegt. Core™ wurde dem BSI nicht vorgelegt. Die Übergabe ist keine BSI-Prüfung, Zertifizierung, Anerkennung oder Bestätigung.
Die immo.quick Serverless Edition™ nutzt keine Trusted Execution Environments (TEEs) und keine Enclaves. TEE- und Enclave-Technologien werden ausschließlich in immo.quick Core™ genutzt. Beide Produkte sind eigenständige Systeme. Core™ ist keine Voraussetzung für die Serverless Edition™.
Die Serverless Edition™ prüft definierte Bedingungen am integrierten Ausführungspfad und dokumentiert die Entscheidung kryptografisch nachvollziehbar. Eine TEE-Attestierung ist kein Bestandteil ihrer Architektur. Hardwaregestützte Isolation und Enclave-Attestierung gehören zum Core-Architekturprofil.
Ein ausreichend leistungsfähiger Quantencomputer existiert heute noch nicht. Das Risiko, das er darstellt, existiert trotzdem schon jetzt, weil verschlüsselter Datenverkehr heute aufgezeichnet und später entschlüsselt werden kann. Wir begegnen genau diesem Risiko mit hybrider Post-Quantum-Kryptografie, ML-KEM und ML-DSA nach FIPS 203 und 204, zusätzlich zu klassischer Kryptografie, nicht anstelle davon.
Ein klassischer Computer prüft mögliche Lösungen im Grunde nacheinander. Ein Quantencomputer nutzt quantenmechanische Effekte, um bestimmte mathematische Probleme auf eine strukturell andere Art anzugehen, für die meisten Alltagsaufgaben ohne Vorteil, für einige wenige mathematische Probleme mit einem fundamentalen Vorteil.
Wir ersetzen klassische Kryptografie nicht durch Post-Quantum-Verfahren, wir kombinieren beide. Ein Angreifer müsste dann sowohl das klassische als auch das neue mathematische Problem gleichzeitig brechen, nicht nur eines von beiden.
Damit gilt für jedes Receipt: Ein Angreifer mit einem Quantencomputer bricht die klassische Signatur, aber nicht die Post-Quantum-Signatur. Ein Angreifer, der eine bislang unbekannte Schwäche im noch jungen Gitter-Verfahren findet, bricht die neue Signatur, aber nicht die klassische. Beide gleichzeitig zu brechen, ist die tatsächliche Sicherheitsschwelle, nicht eine von beiden.
Weder NIS2 noch DORA noch die eIDAS-2.0-Vorgaben schreiben heute eine Post-Quantum-Migration vor. Die hybride Kombination aus ML-KEM, ML-DSA und dem ohnehin quantenresistenten HMAC-SHA256 ist bei uns bereits aktiv, nicht als Reaktion auf eine Pflicht, sondern vorausschauend. Dieselbe Richtung, Post-Quantum-Kryptografie und Zero-Trust-Architektur als Modernisierungspriorität, findet sich auch in der im März 2026 veröffentlichten US-Cyberstrategie für Bundesbehörden wieder, neben dem NIST-Rahmenwerk SP 800-207 zu Zero Trust. Wir folgen damit keiner einzelnen Vorschrift hinterher, wir liegen bereits auf der Linie, in die mehrere große Rahmenwerke gleichzeitig gehen.
Die Signaturschlüssel der Serverless Edition werden lokal auf dem eigenen Server erzeugt. Sie werden nie angezeigt, nie übertragen und liegen nicht bei einem Cloud-Anbieter. Jedes Receipt trägt zwei Signaturen, Ed25519 und ML-DSA-87, und gilt nur, wenn beide stimmen. Die Tageswurzel über alle Receipts eines Tages trägt zusätzlich SLH-DSA-SHA2-256s.
Die Infrastruktur läuft auf Hetzner (DE), IONOS (DE) und OVH (FR), bewusst ohne US-Hyperscaler, um die Reichweite des US Cloud Act strukturell zu vermeiden statt sie vertraglich zu verhandeln. Zwei Regionen laufen Active-Active parallel, eine dritte dient der asynchronen geografischen Replikation für Disaster Recovery.
Bei einem Sicherheitsvorfall greift zuerst die Krypto-Notbremse: betroffene Verfahren werden gesperrt, Ausstellungen brechen technisch ab und werden mit Alarm protokolliert. Jeder Schritt wird selbst wieder im Ledger festgehalten.