Technical Insights

Zutrittskontrolle für das, was eine KI sagt: warum wir GRID gebaut haben

GRID kompiliert Berechtigungen in die Token, die ein Sprachmodell äußern kann. Richtlinienwidrige Abfragen entstehen gar nicht erst. Jetzt quelloffen.

Posted by
Mohsen Arjmandi
Posted date
August 5, 2026

Unser tägliches Geschäft bei evolutionID besteht darin, nachweisbar und mit Protokoll zu entscheiden, wer welche Tür öffnen darf. Ausweisleser verhandeln nicht. Entweder besteht die Berechtigung im Moment des Versuchs, oder die Tür bleibt zu. Und wenn ein Auditor fragt, was im vergangenen März passiert ist, kommt die Antwort aus einem Protokoll, nicht aus der Erinnerung.

Unternehmen binden Sprachmodelle inzwischen in genau diese Welt ein. Das Modell schreibt SQL gegen die Finanzdatenbank, füllt Formulare aus und ruft interne Tools auf. Damit verschiebt sich die Frage von "wer darf diesen Raum betreten" hin zu "was darf dieses System sagen und tun". Die meisten Deployments beantworten sie mit dem Äquivalent eines Schilds an der Tür: einem System-Prompt, der das Modell höflich bittet, oder einem Filter, der die Ausgabe prüft, nachdem das Modell sie bereits erzeugt hat. Wir vertreten die Auffassung, dass die Antwort eher wie ein Ausweisleser funktionieren sollte.

GRID (Grammar-Railed Decoding) ist unsere Antwort darauf, und seit Juli liegt sie quelloffen vor (Apache-2.0, github.com/evolutionIdGmbH/grid, pip install grid-guardrail). GRID kompiliert die Berechtigungen in die Sprache, die das Modell überhaupt äußern kann. Eine Rolle, die Daten ausschließlich lesen darf, erhält eine Grammatik, in der DELETE kein verbotenes Wort ist, sondern ein unmögliches, weil keine Token-Sequenz dorthin führt. Tabellen- und Spaltennamen stammen aus dem Datenbankkatalog, sodass sich Bezeichner, die es nicht gibt, gar nicht buchstabieren lassen. Bei jedem Generierungsschritt wählt das Modell nur unter denjenigen Token, die die Ausgabe innerhalb dessen halten, was die Richtlinie der Rolle zulässt. Das ist Zugriffskontrolle, durchgesetzt auf Ebene des nächsten Tokens.

Drei Eigenschaften übernehmen wir direkt aus unserer Zutritts-DNA:

1. Entscheidungen fallen vor der Aktion, nicht danach. Das Masking greift zur Decode-Zeit, sodass das Modell eine richtlinienwidrige Abfrage von vornherein nicht erzeugt, so wie eine Tür geschlossen bleibt, statt einen Einbruch im Nachhinein zu melden.

2. Jede Entscheidung hinterlässt einen Nachweis. GRID führt einen hash-verketteten Audit-Trail darüber, was das Modell in jedem Schritt äußern durfte, und spielt ihn bit-identisch erneut ab. "Was genau konnte das System am 12. März tun?" hat damit eine belegbare Antwort.

3. Was GRID nicht durchsetzen kann, benennt es. Kein Durchsetzungssystem deckt alles ab, und die ehrlichen sagen das auch. Wenn die Token-Maske eine Bedingung nicht tragen kann, gibt GRID deren Namen im Ergebnis zurück, sodass nachgelagerte Prüfungen genau wissen, was offen bleibt. Das ist der Unterschied zwischen einer Lücke und einem blinden Fleck.

Eines sagen wir deutlich, weil Menschen aus der Zutrittskontrolle klare Aussagen über Grenzen zu schätzen wissen: Token-Masking reduziert Fähigkeiten und stellt für sich genommen keine vollständige Sicherheitsgrenze dar. Wir kombinieren es mit unabhängigen Prüfungen an der Stelle, an der die Ausgabe tatsächlich ausgeführt wird, also derselben mehrstufigen Absicherung, die man von jedem physischen System verlangen würde. Unsere Dokumentation legt ausdrücklich dar, was die Maske nachweislich nicht leisten kann.

Wir benchmarken die Engine offen, über alle 11.306 Schemata des Industriestandards JSONSchemaBench hinweg, gegen die Engines, die in heutigen Serving-Stacks ausgeliefert werden, einschließlich der Zeilen, in denen wir verlieren. Außerdem haben wir die Integration in vLLM vorgeschlagen, den meistgenutzten quelloffenen LLM-Server.

Dieser Beitrag eröffnet unsere Reihe Technical Insights: technische Notizen aus der Entwicklung von GRID und aus dem Alltag mit LLM-Serving. Als Nächstes folgt ein subtiler Pipeline-Bug, der jeden Nutzer eines verbreiteten LLM-Frameworks betrifft, bei dem die deklarierten Bedingungen das Modell möglicherweise nie erreichen. Danach geht es darum, was die Aufzeichnungspflichten des EU AI Act konkret von KI-Systemen verlangen, geschrieben von einem Unternehmen, das seit Jahren Auditoren Auskunft über Zutrittsprotokolle gibt.

MohsenArjmandi ist CTO bei evolutionID GmbH und Autor von GRID.

Über uns
Seit mehr als zwei Jahrzehnten unterstützt evolutionID Organisationen dabei, Klarheit und Kontrolle in ihre Identitäts‑ und Zugangsprozesse zu bringen. Wir konzentrieren uns auf das Wesentliche: sichere, verlässliche Abläufe, die einfach zu bedienen sind und langfristig bestehen.W

ir verbinden Physical Identity & Access Management (PIAM), Karten‑ und Mitarbeitermanagement sowie RFID‑gestützte Workflows zu einem stimmigen Gesamtkonzept. Unsere modularen Bausteine ermöglichen es, Identitäts‑ und Zugangssysteme Schritt für Schritt weiterzuentwickeln – ohne funktionierende Prozesse zu unterbrechen. Das Ergebnis: weniger Komplexität, mehr Transparenz und mehr Sicherheit im täglichen Betrieb.

Als langfristiger Partner begleiten wir unsere Kunden Schritt für Schritt – von Analyse und Architektur über Implementierung und Migration bis hin zu langfristigem Support. Mit Teams in München, Bonn und Frankfurt arbeiten wir eng mit Organisationen in der gesamten DACH‑Region zusammen, um Zugangsstrukturen zu schaffen, die sicher, stabil und bereit für alles sind, was kommt.