语法无法表达的查询不能被提示注入

现在每个人都见过这样的故事——代理被混淆或注入，生产表就没了。标准修复是添加提示：“永远不要运行破坏性命令。”这是用攻击者可以使用的同一种语言编写的防护栏。对于我们代理的记忆引擎，我们将保证下移一层，直接融入语法本身。在查询语言中，DELETE不是一个标记。ERASE、TRUNCATE或GRANT也不是。这些词被词法分析为惰性标识符，解析器在任何操作之前就拒绝它们。唯一能解析的破坏性语句是FORGET <hash>——销毁一条精确的记录，按其内容哈希命名。底层规则是：销毁操作需要一个哈希、一个标识或一个年龄。绝不能是一个谓词。不存在一个可表达的句子意味着“删除所有匹配X的记录”。GDPR删除（“忘记这个人”）和保留（“清除超过90天的数据”）仍然存在——但作为独立的主机端命令，有自己的门控，而不是查询语言可以被诱导执行的句子。这是三层防护，因为每一层的失败方式不同：词法分析器黑名单、带有专用错误的解析器快速拒绝，以及每个进程的终止开关（--no-destructive-ops为你提供完全只读会话；在服务器上，即使是单条记录的FORGET也需要管理员权限）。在构建过程中让我明白的是：系统提示中的“永远不要删除”是一个请求。语法中缺失DELETE是一个事实。提示注入无法使解析器接受一个不存在的句子。诚实的局限：这保护了记忆存储，而非任意工具——给你的代理一个bash工具，任何语法都救不了你。代码库链接在评论中。好奇其他人如何划定这条线：你是净化代理发出的查询，将代理指向只读副本，还是将安全性推入查询表面本身？