AI-BOUNDARY-2.0 · 2026-11-02
The immo.quick Serverless Edition checks the protected execution path immediately before the called function runs its first instruction. This boundary applies to human calls as well as calls from functions and workflows. It does not grant an AI agent an execution right. The publisher reported the following internally tested state on 2 November 2026.
The overview reads its state from runtime checks: integrity seal and audit chain, cryptographic schemes, permitted connection destinations, logins and sessions, key provenance without key values, runtime permissions and the AI boundary. A snapshot can be captured with a receipt.
Each handling step is recorded with a receipt. The system calculates configured reporting deadlines and records the authority and case reference. A human submits the notification. An incident can only be closed once all required notifications are recorded. The statutory timing anchors and scope limits are explained below the cards.
An administrator can end all sessions of an account together. Only the owner can end the owner’s sessions. Session revocation remains a separate access control.
Every use of AI must be registered. Unregistered use is rejected. Verdicts and approvals are removed from AI responses. An AI response establishes neither a domain approval nor an execution right.
AI never holds an execution right in this system. There is therefore no AI kill switch as a system feature. Immediately before a protected execution function runs its first instruction, the runtime checks the input. A call by an AI agent, or AI-origin input without human confirmation for that exact function, is rejected. The rejected operation is not executed. Its rejection receives a receipt recording BLOCK, the function reference and “nothing executed”. Human confirmation does not replace other authority or execution checks.
An AI agent’s proposals have no direct effect. The agent cannot call an execution function, cause a data change or grant approval. It never becomes an administrator. Only the owner may designate an account as an AI agent.
The reported software bill of materials contains 746 components, each with a pinned version and checksum. This inventory is version-specific and is not an external security certification.
The publisher reports a fully passing internal test suite and 46 AI guardrail checks, including adversarial tests. Rejection tests observed no database writes by the rejected execution path. The rejection receipt documents this boundary; it is not execution permission. An external penetration test has not yet been performed. Internal tests replace neither that assessment nor certification.
Login: the second factor is disabled in the reported state by the owner’s decision. This is a documented operating setting, not a statement that institutional authentication requirements have been met.
For significant incidents, the general sequence is an early warning within 24 hours and an incident notification within 72 hours of awareness. The final report is due within one month after the incident notification. Ongoing incidents and trust services have specific rules; applicable national implementation governs.
EUR-Lex · NIS2 · Article 23Initial notification as early as possible, within four hours of classification as a major ICT-related incident and generally within 24 hours of awareness. If classification occurs after those 24 hours, the four-hour period runs from classification. Statutory follow-up reporting deadlines must be considered separately.
EUR-Lex · DORA · Delegated Regulation (EU) 2025/301, Article 5A notifiable personal data breach must be reported without undue delay and, where feasible, within 72 hours of awareness. The exception for breaches unlikely to pose a risk, and the requirement to explain a late notification, remain applicable.
EUR-Lex · GDPR · Article 33New: Which cyber protections apply automatically once the Serverless Edition is connected through its API: Cybersecurity via API →
immo.quick separates access from execution authority. A request must first pass the relevant entry boundary; even successful access does not yet authorise a productive effect.
Core™ places a fail-closed access guardian in front of the governance and compliance pipeline. If a required validation condition fails, the request never reaches the downstream governance logic.
Die Serverless Edition™ already requires a valid attestation of a registered client at the edge before the request reaches the downstream gate path.
Access is not authority. A productive effect requires a valid, current and scope-bound execution right and an executable capability.
Claim boundary: Only the architecture of immo.quick Serverless Edition™ was demonstrably submitted to the BSI on 28 July 2026. Core™ was not submitted to the BSI. The submission is not a BSI review, certification, recognition or endorsement.
The immo.quick Serverless Edition™ uses no Trusted Execution Environments (TEEs) and no enclaves. TEE and enclave technologies are used exclusively in immo.quick Core™. The two products are independent systems. Core™ is not a prerequisite for the Serverless Edition™.
The Serverless Edition™ checks defined conditions at the integrated execution path and records the decision in cryptographically verifiable evidence. TEE attestation is not part of its architecture. Hardware-backed isolation and enclave attestation belong to the Core™ architecture profile.
A sufficiently powerful quantum computer does not exist yet. The risk it poses already exists today, because encrypted traffic can be recorded now and decrypted later. We meet exactly that risk with hybrid post-quantum cryptography, ML-KEM and ML-DSA per FIPS 203 and 204, in addition to classical cryptography, not instead of it.
A classical computer essentially checks possible solutions one after another. A quantum computer uses quantum-mechanical effects to approach certain mathematical problems in a structurally different way, no advantage for most everyday tasks, a fundamental advantage for a small number of specific mathematical problems.
We do not replace classical cryptography with post-quantum methods, we combine both. An attacker would then have to break both the classical and the new mathematical problem at the same time, not just one of the two.
This means for every receipt: an attacker with a quantum computer breaks the classical signature, but not the post-quantum signature. An attacker who finds a still-unknown weakness in the comparatively young lattice-based method breaks the new signature, but not the classical one. Breaking both simultaneously is the actual security threshold, not either one alone.
Neither NIS2 nor DORA nor the eIDAS 2.0 provisions currently mandate a post-quantum migration. The hybrid combination of ML-KEM, ML-DSA, and the already quantum-resistant HMAC-SHA256 is already active for us, not as a reaction to an obligation, but ahead of one. The same direction, post-quantum cryptography and zero-trust architecture as a modernisation priority, also appears in the US federal cyber strategy published in March 2026, alongside the NIST SP 800-207 Zero Trust framework. We are not following a single rule after the fact, we already sit on the line several major frameworks are converging toward at the same time.
The Serverless Edition's signing keys are generated locally on the own server. They are never displayed, never transmitted and do not sit with a cloud provider. Every receipt carries two signatures, Ed25519 and ML-DSA-87, and is valid only if both verify. The daily root over all receipts of a day additionally carries SLH-DSA-SHA2-256s.
Infrastructure runs on Hetzner (DE), IONOS (DE) and OVH (FR), deliberately without a US hyperscaler, to structurally avoid the reach of the US Cloud Act rather than negotiate around it contractually. Two regions run active-active in parallel, a third provides asynchronous geographic replication for disaster recovery.
In a security incident the compromised-scheme issuance block acts first: affected schemes are blocked, issuance aborts technically and is logged with an alarm. Every step is itself recorded in the ledger.