GRID compiles access permissions into the tokens a language model can emit, so a policy-violating query is never generated in the first place. Now open source.
Our daily business at evolutionID is deciding, provably and with a record, who can open which door. Badge readers don't negotiate. Either the permission exists at the moment of the attempt, or the door stays closed. When an auditor asks what happened last March, the answer comes from a log, not from memory.
Enterprises now wire language models into that same world. The model writes SQL against the finance database, fills forms, and calls internal tools. The question shifts from who may enter this room to what this system may say and do. Most deployments answer it with the equivalent of a sign on the door: a system prompt that asks the model nicely or a filter that checks the output after the model has already generated it. We took the view that the answer should work more like a badge reader.
GRID (Grammar-Railed Decoding) is our answer, and it has been open source since July (Apache-2.0, github.com/evolutionIdGmbH/grid, pip install grid-guardrail). It compiles the permissions into the language the model is able to emit. A role that may only read data gets a grammar in which DELETE is not a forbidden word but an impossible one, because no sequence of tokens reaches it. Table and column names come from the database catalog, so identifiers that don't exist cannot be spelled. At every generation step, the model chooses only among tokens that keep the output inside what the role's policy allows. That is access control, enforced at the level of the next token.
Three properties carry over directly from our access-control DNA:
1. Decisions happen before the action, not after. Masking happens at decode time, so the model never generates a policy-violating query in the first place, the way a door stays shut rather than an intrusion getting flagged afterward.
2. Every decision leaves a record. GRID keeps a hash-chained audit trail of what the model was permitted to emit at every step, and it replays bit-identically. "What exactly could the system do on March 12?" has a provable answer.
3. What GRID cannot enforce, it names. No enforcement system covers everything, and the honest ones say so. When the token mask cannot carry a constraint, GRID returns that constraint's name in the result, so downstream checks know exactly what remains open. That is the difference between a gap and a blind spot.
One thing we state plainly, because access-control people appreciate plain statements about boundaries: token masking reduces capability, and it is not a complete security boundary on its own. We pair it with independent checks at the point where the output actually executes, the same defense in depth you would demand of any physical system. Our documentation sets out explicitly what the mask provably cannot do.
We benchmark the engine in the open, across all 11,306 schemas of the industry-standard JSONSchemaBench, against the engines that ship in today's serving stacks, including the rows where we lose. We have also proposed integrating it into vLLM, the most widely used open-source LLM server.
This post opens our Technical Insight series: engineering notes from building GRID and from the LLM-serving trenches. Next up, a subtle pipeline bug that affects every user of a popular LLM framework, where your declared constraints may never reach the model at all. After that, what the EU AI Act's record-keeping obligations actually ask of AI systems, written by a company that has been answering auditors about access records for years.
Mohsen Arjmandi is CTO at evolutionID GmbH and the author of GRID.
