KI-Sicherheit durch Architektur | Air-Gapped RAG in Rust | Lexiane

Die Sicherheit eines KI-Systems in der Produktion lässt sich nicht auf eine Liste von Maßnahmen reduzieren, die nach dem Deployment angewendet werden. Sie ist die Konsequenz einer Reihe von Architekturentscheidungen, die im Vorfeld getroffen werden — über die Programmiersprache, die Systemgrenzen, die Speicherverwaltung und die Expositionsflächen. Diese Entscheidungen bestimmen, was ein Angreifer erreichen kann, was das System preisgeben kann, und was ein Prüfer verifizieren kann.

Lexiane wurde nach dieser Logik konzipiert: Jede Sicherheitseigenschaft ist entweder mechanisch durch den Compiler garantiert, durch einen automatisierten Test in der kontinuierlichen Integration geprüft, oder durch die Architektur physisch unmöglich gemacht. Es gibt keine Sicherheitseigenschaften, die ausschließlich auf Entwicklungskonventionen oder der individuellen Wachsamkeit der Teams beruhen.

---

Die Bedrohungslandschaft spezifisch für RAG-Systeme

RAG-Systeme führen Angriffsvektoren ein, die in traditionellen Softwaresystemen nicht existieren. OWASP veröffentlichte 2023, aktualisiert 2025, ein Referenzwerk zu den zehn prioritären Risikokategorien für LLM-Anwendungen — das OWASP LLM Top 10. Unter den kritischsten für ein Dokumentenverarbeitungssystem:

LLM01 — Prompt-Injection. Ein Angreifer fügt in eine Anfrage Anweisungen ein, die darauf abzielen, die Systemrichtlinien zu umgehen, Daten zu exfiltrieren oder nicht konforme Inhalte zu erzeugen. In einem RAG-System, das nicht vollständig vertrauenswürdigen Nutzern ausgesetzt ist — externen Agenten, internen Benutzern mit eingeschränkten Rechten —, ist dieser Vektor am häufigsten ausgenutzt.

LLM06 — Offenlegung sensibler Informationen. Das Sprachmodell kann Antworten erzeugen, die Daten aus dem abgerufenen Kontext einbeziehen, einschließlich personenbezogener Daten oder vertraulicher Informationen, die der anfragende Benutzer nicht sehen sollte. In einem Multi-User-Korpus schafft das Fehlen von Zugriffskontrollen auf der Abrufebene dieses Risiko systematisch.

LLM02 — Unsichere Ausgabeverarbeitung. Die Ausgaben des LLM werden ohne ausreichende Validierung verwendet — in Weboberflächen (XSS), in Systemaufrufen oder ohne Filterung an andere Systeme weitergeleitet. LLM-Ausgaben sind nicht vertrauenswürdige Daten und müssen als solche behandelt werden.

LLM09 — Übermäßiges Vertrauen in Modellausgaben. Ein System, das LLM-Antworten ohne Überprüfung ihrer Verankerung in dokumentarischen Quellen akzeptiert und weiterleitet, öffnet den Weg zur operationellen Desinformation — falsche Antworten, die mit dem gleichen Anschein von Zuverlässigkeit präsentiert werden wie korrekte.

Zu diesen LLM-spezifischen Bedrohungen kommen klassische Bedrohungen hinzu, die durch die Komplexität von KI-Stacks verstärkt werden: Speichervulnerabilitäten, die durch C/C++-Abhängigkeiten unter Python-Frameworks eingeführt werden, Software-Lieferkette (Supply Chain), erweiterte Angriffsfläche durch Nebenprozesse und Netzwerkaufrufe.

Lexiane adressiert jede dieser Kategorien — durch unterschiedliche, überprüfbare und dokumentierte Mechanismen.

---

Speichersicherheit: Was Rust strukturell ausschließt

Die Klasse von Schwachstellen, die Python und C++ nicht eliminieren können

Speicherverwaltungsschwachstellen — Buffer Overflow, Use-After-Free, Double Free, Null-Pointer-Dereferenzierung, Memory Race Conditions — machen historisch gesehen den Großteil kritischer Sicherheitslücken in Softwaresystemen aus. Google hat im Android-Projekt dokumentiert, dass die Einführung von Rust als Systemsprache die speicherbezogenen Schwachstellen über fünf Jahre um 68 % reduziert hat. Microsoft schätzte, dass 70 % der kritischen CVEs in seinen Produkten ihren Ursprung in Speicherverwaltungsfehlern haben.

Python-RAG-Frameworks verwenden für ihre intensiven Operationen C- und C++-Bibliotheken — PyTorch, NumPy, native Parser, Komprimierungsbibliotheken. Diese Abhängigkeiten erben alle Schwachstellenklassen der nicht memory-safe Sprachen. Eine Schwachstelle in einer transitiven Abhängigkeit — im Python-Oberflächencode unsichtbar — kann das gesamte System kompromittieren.

Was der Rust-Compiler garantiert

Rust eliminiert auf Compiler-Ebene vollständige Kategorien der oben genannten Speicher-Bugs durch Konstruktion:

• Keine Null-Pointer-Dereferenzierungen — optionale Werte werden über Option<T> ausgedrückt, deren erschöpfende Behandlung vom Compiler gefordert wird.
• Kein Use-After-Free — das Ownership-System von Rust garantiert, dass auf eine freigegebene Ressource nicht mehr zugegriffen werden kann. Diese Eigenschaft wird statisch, ohne dynamische Analyse, geprüft.
• Keine Data Races — das Typsystem von Rust garantiert gegenseitigen Ausschluss zwischen gleichzeitigen veränderbaren Zugriffen. Eine Data Race ist ein Compilerfehler, keine Race Condition, die in der Produktion entdeckt wird.
• Kein unkontrollierter arithmetischer Overflow — im Debug-Modus werden Overflows erkannt und lösen einen Panic aus. Im Release-Modus ist das Verhalten definiert und konfigurierbar — niemals ein exploitierbares undefiniertes Verhalten.

#![forbid(unsafe_code)] auf dem zertifizierten Perimeter

Rust erlaubt das Schreiben von “unsafe”-Code — Blöcken, in denen die Compiler-Garantien ausgesetzt sind, die für die Interaktion mit C-Schnittstellen oder dem System notwendig sind. Diese Funktion ist eine Falle: In einer Codebasis ohne Disziplin kann sie die Schwachstellen wieder einführen, die Rust eliminieren soll.

Der zertifizierte Kern von Lexiane (vectrant-core) trägt die Direktive #![forbid(unsafe_code)]. Diese Direktive ist keine Konvention — sie wird vom Compiler durchgesetzt. Kein Entwickler kann einen unsafe-Block in den zertifizierten Perimeter einführen, auch nicht versehentlich, auch nicht unter Termindruck. Der Compiler lehnt den Code ab, bevor das Binär existiert.

Im Dezember 2023 veröffentlichte die CISA (Cybersecurity and Infrastructure Security Agency) “The Case for Memory Safe Roadmaps”, in dem explizit die Einführung von memory-sicheren Sprachen — einschließlich Rust — für kritische Systeme empfohlen wird. Das US-Verteidigungsministerium und das Weiße Haus haben übereinstimmende Empfehlungen herausgegeben. Lexiane erfüllt diese Vorgaben durch Architektur.

---

Reduzierung der Angriffsfläche

Ein Binär, kein Ökosystem

Jede externe Abhängigkeit ist ein potenzieller Angriffsvektor. Ein Python-System in der Produktion exponiert eine erweiterte Angriffsfläche: den Python-Interpreter, über pip installierte Pakete, dynamisch geladene gemeinsame Systembibliotheken, Nebenprozesse (Ollama-Server, Redis-API, Celery-Worker). Ein Angreifer, der eine Abhängigkeit kompromittiert — durch eine Zero-Day-Schwachstelle oder einen Supply-Chain-Angriff — kann das gesamte System kompromittieren.

Lexiane kompiliert zu einem autonomen statischen Binär. Es lädt keine gemeinsamen Bibliotheken zur Laufzeit. Es löst beim Start keine Abhängigkeiten auf. Es lädt während seiner Ausführung keinen externen Code herunter. Die Angriffsfläche wird durch das Binär selbst begrenzt — ein fester, auditierbarer, reproduzierbarer Perimeter.

Sicherheit der Lieferkette

Software-Supply-Chain-Angriffe — Kompromittierung eines Open-Source-Pakets zur Injektion von Schadcode in abhängige Anwendungen — nehmen ständig zu. Der PyPI-Index hat in den letzten Jahren zahlreiche solcher Vorfälle erlitten.

Lexiane adressiert dieses Risiko durch zwei komplementäre Mechanismen:

Null Vendor-Abhängigkeiten im zertifizierten Kern. Das Modul vectrant-core — der Kern des Systems — enthält keine Abhängigkeiten zu einem Drittanbieter. Diese Einschränkung wird durch einen automatisierten Test verifiziert, der bei der Kompilierung scheitert, wenn eine externe Abhängigkeit eingeführt wird. Die Regression ist ohne sofortige Erkennung unmöglich.

Kompilierung mit Ferrocene. Ferrocene ist die qualifizierte Version des Rust-Compilers, entwickelt von Ferrous Systems — qualifiziert nach ISO 26262 ASIL D und IEC 61508 SIL 4. Die Kompilierung von Lexiane mit Ferrocene ermöglicht es, eine vollständige Vertrauenskette für die Zertifizierung zu etablieren: vom Quellcode, über den Compiler, bis zum deployen Binär. Ein Angreifer, der Schadcode einführen möchte, müsste den Compiler selbst kompromittieren — dessen Qualifikation eine strenge Rückverfolgbarkeit vorschreibt.

Keine Nebenprozesse

Alternative Rust-RAG-Frameworks — Swiftide, Rig — benötigen einen externen Inferenzserver für die Texterzeugung: einen Ollama-Prozess, einen OpenAI-Endpunkt oder einen vLLM-Server. Dieser Sekundärserver ist eine unabhängige Netzwerkkomponente: seine Angriffsfläche kommt zur Angriffsfläche des RAG-Frameworks hinzu, und die Kommunikation zwischen den beiden Komponenten schafft einen potenziell abhörbaren Kanal.

Lexiane integriert LLM-Inferenz (Mistral.rs) und Embeddings (Candle) in dasselbe Binär. In lokaler Konfiguration gibt es keinen Sekundärprozess, keine interne Netzwerkkommunikation, keinen zu sichernden Interprozesskommunikationskanal.

---

KI-spezifische Sicherheit

Abwehr von Prompt-Injection

Der InputGuardrail-Port von Lexiane implementiert eine Validierungsschicht für eingehende Anfragen, bevor diese die Abruf-Pipeline oder das Sprachmodell erreichen. Prompt-Injection-Muster — versteckte Anweisungen in der Anfrage, Versuche zur Umgehung der Systemrichtlinien, Rechteerweiterung durch Prompt-Manipulation — werden an dieser Stelle erkannt und blockiert.

Dieser Mechanismus operiert vorgelagert der Pipeline: Eine vom InputGuardrail blockierte Anfrage erzeugt kein Embedding, löst keinen Abruf aus und beansprucht kein LLM. Es gibt keine Rechenkosten für blockierte Schadanfragen und kein Risiko, dass deren Inhalt das Modellverhalten beeinflusst.

Kontrolle der Modellausgaben

Der OutputGuardrail-Port validiert die erzeugte Antwort vor der Übermittlung an den Benutzer. Drei Risikokategorien werden adressiert:

Leckage sensibler Daten. Das LLM kann in seiner Antwort Daten aus dem abgerufenen Kontext einbetten — einschließlich personenbezogener Daten, die der Benutzer nicht hätte sehen sollen, oder vertraulicher Informationen aus Dokumenten, die über den Abrufmechanismus zugänglich sind. Der OutputGuardrail erkennt diese Lecks und blockiert sie vor der Übermittlung.

Toxische oder nicht konforme Inhalte. Antworten, die gegen die von der Organisation definierten Inhaltsrichtlinien verstoßen — diskriminierende Inhalte, gefährliche Anweisungen, außerhalb des Geltungsbereichs liegender Inhalt — werden abgefangen, bevor sie den Benutzer erreichen.

Nicht verankerte Antworten. Der FaithfulnessChecker verifiziert, dass die erzeugte Antwort tatsächlich durch die abgerufenen Quellen gestützt wird. Eine Antwort, die über den bereitgestellten Kontext hinaus extrapoliert — d.h. eine Halluzination — wird erkannt und kann eine Enthaltung oder eine Markierung auslösen.

Zugangskontrolle auf Dokumentenebene

Der AccessControl-Port implementiert eine Filterung der Abrufergebnisse basierend auf den Rechten des anfragenden Benutzers. Diese Filterung erfolgt vor der Generierung: Dokumente, auf die der Benutzer keinen Zugriff hat, werden dem LLM nicht als Kontext übermittelt.

Diese Position in der Pipeline ist kritisch. Eine Zugangskontrolle, die nur auf der Benutzeroberfläche angewendet wird — indem bestimmte Antworten in der UI ausgeblendet werden —, lässt sensible Daten durch das Sprachmodell fließen. Ein LLM, das ein vertrauliches Dokument in seinem Kontext erhalten hat, kann dessen Inhalt indirekt offenbaren, auch wenn die endgültige Antwort scheinbar nicht darauf Bezug nimmt. Lexiane schneidet diesen Vektor an der Quelle ab.

Zwei Zugangskontrollmodelle werden unterstützt:

• RBAC (Role-Based Access Control) — Zugriffsrechte werden durch die Rolle des Benutzers in der Organisation definiert.
• ABAC (Attribute-Based Access Control) — Zugriffsrechte werden durch kontextbezogene Attribute definiert: Dokumentenklassifikation, besitzendes Department, Sensitivitätsstufe, Veröffentlichungsdatum.

Das Relevanztor als Schutz vor operationeller Desinformation

Der RelevanceGateStage bewertet den globalen Vertrauensscore des abgerufenen Kontexts vor der Generierung. Unterhalb des konfigurierten Schwellenwerts enthält sich das System der Generierung einer Antwort und signalisiert dies explizit.

Dieses Enthaltungsverhalten ist eine operative Sicherheitsmaßnahme: In einer Entscheidungsumgebung — medizinisch, rechtlich, industriell, nachrichtendienstlich — ist eine schlecht begründete Antwort, die mit dem gleichen Erscheinungsbild wie eine zuverlässige präsentiert wird, gefährlicher als keine Antwort. Lexiane bevorzugt Transparenz über Unzulänglichkeit gegenüber der Produktion einer unbelegten Antwort.

---

Datenschutz

Der PII-Filter als erste Verteidigungslinie

Der PII-Filter operiert vorgelagert der gesamten Dokumentenverarbeitungs-Pipeline — vor jedem Embedding, vor jeder Indexierung, vor jedem LLM-Aufruf. Personenbezogene Daten, die in den aufgenommenen Dokumenten erkannt werden, werden gemäß konfigurierbarer Richtlinien behandelt: typisierte Maskierung, Löschung, kryptografisches Hashing.

Der Audit-Trail zeichnet für jedes Dokument die erkannten Kategorien personenbezogener Daten und die angewandten Richtlinien auf. Dieses Register stellt den technischen Nachweis der konformen Verarbeitung dar — verwendbar im Rahmen einer DSGVO-Kontrolle.

Datenwohnsitz als physische Garantie

In der Air-Gapped-Konfiguration verlassen die Daten den Perimeter nicht, weil die Architektur dies physisch unmöglich macht — nicht weil ein Vertrag es verbietet. Das Binär verfügt über keine aktive Netzwerkschnittstelle nach außen. Es gibt keine zu überwachenden Flüsse, keine vertraglichen Verpflichtungen zu auditieren: Die Eigenschaft ist mechanischer Natur.

Diese Unterscheidung — Architekturgarantie versus Vertragsgarantie — ist fundamental für Organisationen, deren Daten einer strengen Lokalisierungsanforderung unterliegen: Verteidigung, Nachrichtendienste, Gesundheitswesen, öffentlicher Sektor mit souveränen Cloud-Referenzwerken.

---

Audit und Forensik

Eine unverletzliche SHA-256-Kette

Jede Aktion der Pipeline wird in einer kryptografischen Audit-Kette aufgezeichnet: Jeder Eintrag ist mit dem SHA-256-Hash des vorherigen signiert. Jede nachträgliche Änderung eines Eintrags — Löschung eines Zugriffs, Änderung eines Zeitstempels, Änderung einer angewandten Richtlinie — bricht die Kette und ist mathematisch erkennbar.

Im Falle eines Sicherheitsvorfalls ermöglicht diese Kette eine vollständige forensische Rekonstruktion: Wer hat wann auf was zugegriffen, mit welchem Ergebnis, gemäß welcher Filterrichtlinie. Die Untersuchung hängt nicht von der Verfügbarkeit von Anwendungsprotokollen ab, die möglicherweise geändert oder gelöscht wurden. Die Kette ist der Beweis.

Aufgezeichnete Ereignisse:

Ereignis	Aufgezeichnete Daten
Aufgenommenes Dokument	Kennung, Inhalts-Hash, Zeitstempel, Sammlung
Erkannte personenbezogene Daten	Kategorien, angewandte Richtlinie, Position im Dokument
Benutzeranfrage	Benutzerkennung, Anfragetext, Zeitstempel
Abgerufene Dokumente	Kennungen, Relevanzscore, Zugang gewährt oder verweigert
Erzeugte Antwort	Antwort-Hash, zitierte Quellen, Treue-Score
Ausgelöster Guardrail	Art des Guardrails, Blockierungsgrund, Benutzerkennung

Keine Leckskanäle durch Protokolle

Ein häufig vernachlässigter Daten-Leckkanal in KI-Systemen ist die Anwendungsprotokollierung: sensible Daten in Anfragen oder Antworten, die im Klartext in Systemprotokollen auftauchen. Lexiane verbietet durch Entwicklungskonvention die Verwendung von println!() im gesamten Produktionscode. Jede Protokollausgabe erfolgt über das tracing-Framework, mit kontrollierbaren Verbositätsniveaus und Strukturierungsfiltern. Diese Eigenschaft wird in der kontinuierlichen Integration verifiziert.

---

Was Ihr Sicherheitsteam verifizieren kann

Die Sicherheit von Lexiane beruht nicht auf Aussagen. Jede Eigenschaft ist entweder im Quellcode überprüfbar, in den Build-Artefakten verifizierbar oder durch Inspektion des Binärs demonstrierbar.

Sicherheitseigenschaft	Verifikationsmechanismus
Kein Unsafe-Code im Kern	#![forbid(unsafe_code)] — Quellcode-Inspektion
Kein unwrap() / panic!() in der Produktion	Automatisierter Test in CI — Ergebnis in der Testsuite prüfbar
Null Vendor-Abhängigkeiten im Kern	Automatisierter Test bei Kompilierung — vectrant-core/Cargo.toml einsehbar
Integrität des Audit-Trails	Kryptografische SHA-256-Eigenschaft — algorithmisch verifizierbar
PII-Filterung vor Indexierung	Position in der Pipeline — in der Reihenfolge der Ingestion-Stages einsehbar
Zugangskontrolle vor Generierung	Position des AccessControl-Ports in der Pipeline — in der Assembly einsehbar
Kein println!()	Durch Grep über den gesamten Quellcode überprüfbar
Statische Konfigurationsvalidierung	Eigenschaft des Assemblers — in den Assembly-Tests einsehbar
Kein Netzwerkaufruf im Air-Gapped-Modus	In der Konfiguration der aktiven Adapter einsehbar

---

Häufige Fragen von Sicherheitsteams und CISOs

Haben Sie einen Penetrationstest an Lexiane durchgeführt? Die Ergebnisse eines externen Sicherheitsaudits sind auf Anfrage im Rahmen einer qualifizierten Diskussion verfügbar. Die in diesem Dokument beschriebenen mechanischen Eigenschaften — kein Unsafe-Code, auf das Binär reduzierte Angriffsfläche, unverletzliche Audit-Kette — sind unabhängig von Ihrem Sicherheitsteam oder einem Dienstleister Ihrer Wahl verifizierbar.

Ist Lexiane mit dem OWASP LLM Top 10 konform? Die Architektur von Lexiane adressiert direkt die Kategorien LLM01 (Prompt-Injection über InputGuardrail), LLM02 (Ausgabevalidierung über OutputGuardrail und FaithfulnessChecker), LLM06 (PII-Filterung und AccessControl vor Generierung) und LLM09 (Relevanztor und Enthaltung). Die vollständige OWASP-Konformitätsbewertung für Ihr spezifisches Deployment verbleibt gemäß Ihrem Kontext durchzuführen.

Wie werden Secrets — API-Schlüssel, Tokens — in der Konfiguration verwaltet? Lexiane folgt der api_key_env-Konvention: Konfigurationsfelder referenzieren den Namen der Umgebungsvariablen, die den Schlüssel enthält, niemals den Schlüssel selbst. Secrets fließen nicht durch TOML-Konfigurationsdateien. Sie werden über Umgebungsvariablen beim Start injiziert — kompatibel mit Standard-Secret-Managern (Vault, Kubernetes Secrets, AWS Secrets Manager).

Was ist die Richtlinie für Abhängigkeits- und CVE-Management? Die Projektabhängigkeiten werden einem automatisierten Sicherheits-Audit (cargo audit) in der kontinuierlichen Integration unterzogen. In Abhängigkeiten erkannte CVEs lösen sofort eine Warnung aus. Die Anzahl der aktiven Abhängigkeiten wird so gering wie möglich gehalten — jede hinzugefügte Abhängigkeit ist eine bewusste Entscheidung, kein Nebeneffekt.

Kann Lexiane in einer Umgebung mit einer Web Application Firewall (WAF) bereitgestellt werden? Ja. Die REST-API von Lexiane ist eine Standard-HTTP-API, kompatibel mit allen WAFs am Markt. In der Air-Gapped-Konfiguration gilt die WAF-Frage nur für interne Flüsse — Lexiane selbst initiiert keine ausgehenden Netzwerkflüsse.

Wie werden Zugriffsrechte zwischen mehreren Teams, die dieselbe Lexiane-Instanz verwenden, isoliert? Der AccessControl-Port ermöglicht eine Segmentierung der Rechte auf Dokumentenebene. Aufgenommene Dokumente können mit Klassifikationsattributen (RBAC oder ABAC) versehen werden, und die Zugriffsrechte werden beim Abruf geprüft — bevor der Kontext an das Modell übermittelt wird. Mehrere Teams können dieselbe Infrastruktur teilen, ohne dass ihre Dokumentkorpora sich in den Antworten vermischen.

---

Beginnen Sie das Gespräch über Ihr Bedrohungsmodell.

Die Sicherheit eines KI-Systems basiert auf einer Bedrohungsanalyse, die Ihrem Kontext eigen ist: Ihrem Sektor, Ihrem Benutzerzugriffsmodell, Ihrer Deployment-Infrastruktur und Ihren regulatorischen Anforderungen. Wir bieten keine generische Bewertung an.

Wir bieten einen strukturierten Austausch mit einem Team, das die spezifischen Angriffsvektoren von RAG-Systemen, die Einschränkungen regulierter Umgebungen und die Beweise kennt, die die Architektur von Lexiane Ihren Sicherheitsteams liefern kann.

Was Sie erwarten können:

• Eine Antwort innerhalb von 48 Geschäftsstunden
• Einen technischen Ansprechpartner, der das OWASP LLM Top 10, die Anforderungen klassifizierter Umgebungen und Zertifizierungsanforderungen kennt
• Eine ehrliche Kartierung dessen, was die Architektur von Lexiane abdeckt — und was in Ihrer Verantwortung verbleibt

→ Kontakt aufnehmen

Keine kommerzielle Verpflichtung. Ein Sicherheitsgespräch.

---

In diesem Dokument zitierte Referenzen: — OWASP LLM Top 10, Version 1.1 (2023), aktualisiert 2025 — owasp.org/www-project-top-10-for-large-language-model-applications — CISA, “The Case for Memory Safe Roadmaps”, Dezember 2023 — Google, “Memory Safe Languages in Android 13”, Android Security Blog — NIST AI Risk Management Framework 1.0, Januar 2023 — Verordnung (EU) 2016/679 (DSGVO)