You can't prompt-inject a query the grammar can't express

Everyone's seen the stories by now — an agent gets confused or injected, and a production table is gone. The standard fix is a prompt: "never run destructive commands." That's a guardrail written in the same language the attacker gets to use. For our agent memory engine we moved the guarantee down a layer, into the grammar itself. In the query language, DELETE is not a token. Neither is ERASE, TRUNCATE, or GRANT. Those words lex as inert identifiers and the parser rejects them before anything dispatches. The only destructive statement that parses at all is FORGET <hash> — destroy exactly one record, named by its content hash. The rule underneath: destruction takes a hash, an identity, or an age. Never a predicate. There is no expressible sentence that means "delete everything matching X." GDPR erasure ("forget this person") and retention ("purge older than 90 days") still exist — but as separate host-side commands with their own gates, not sentences the query language can be talked into. It's three layers, because each fails differently: the lexer blocklist, a parser fast-reject with a dedicated error, and a per-process kill switch (--no-destructive-ops gives you a fully read-only session; on the server, even single-record FORGET needs admin scope). The thing that clicked for me while building it: "never delete" in a system prompt is a request. DELETE missing from the grammar is a fact. A prompt injection can't make a parser accept a sentence that doesn't exist. Honest limit: this protects the memory store, not arbitrary tools — hand your agent a bash tool and no grammar will save you. Repo link in the comments. Curious where others draw this line: do you sanitize agent-issued queries, point agents at read-only replicas, or push safety into the query surface itself?