Deterministic gate for containing unauthorized LLM record updates

[iseyan]

I’ve released a small local Python demo that separates LLM-generated proposals from authoritative record updates.
The model proposes an update. A deterministic Python gate — not another LLM — checks the state reference, admitted evidence, and permitted candidate changes before anything is saved. Evidence authorization is defined outside the model, and proposals cannot disable future checks.
Observations from V1:

• Four fixed invalid-update types were rejected with the stored records unchanged: unsupported resolution, forged evidence admission, future-check bypass, and state-reference tampering.
• A supported GPT-generated update was accepted and saved, advancing the record from Version 1 to Version 2.
• In a separate adversarial GPT run, the model itself preserved uncertainty, so the gate received a valid no-change proposal rather than rejecting an invalid one.
  The current demo includes an OpenAI model connection, but the gate itself does not depend on another LLM call. The model is treated only as an untrusted proposer; the authoritative state and commit decision remain outside it.
  The app exposes inputs, proposals, gate decisions, and saved records for inspection and JSON export.
  Scope is deliberately narrow: it protects case-record updates through this path. It does not establish whether evidence is true or control external tools.
  Source code, reproduction instructions, and observation records:
  https://github.com/iseyan/M-Anchor-App
  I’d especially welcome adversarial examples or reproducible cases where the gate accepts an unauthorized update or blocks a valid one.

[xxh031203]

这是来自QQ邮箱的假期自动回复邮件。   您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

[iseyan]

Thanks for the thoughtful questions. One clarification: the gate does not infer self-modification attempts from natural language. Its accepted proposal schema and permitted state writes are fixed outside the model; proposals cannot change the validation policy. In the “future-check bypass” case, future_bypass_authorized: true is explicitly rejected as authority_escalation. The version/hash checks separately verify that the proposal references the current stored state—they do not authorize policy changes. For the mixed case, the current code rejects the whole proposal when that bypass flag is true, even if the candidate update would otherwise be valid. It does not partially apply the update. The published bypass example is a fixed-proposal test, not a demonstration of detecting arbitrary recursive attacks. A concrete edge case against this boundary would be very welcome. 2026年10月3日(土) 9:45 yelefab449 ***@***.***>:

…

This is a really solid approach to handling LLM outputs in safety-critical workflows. Separating the "proposal" phase from the "commit" phase is the right architectural decision; treating the model as an untrusted input source rather than an authority is exactly where the industry needs to be heading. I was curious about the "future-check bypass" rejection case you mentioned. How does the gate specifically detect attempts to modify its own validation logic? I’ve been experimenting with similar deterministic gates for internal data pipelines, and catching recursive or self-modifying proposals is often the trickiest part. It seems like you’re relying on the state reference to detect anomalies, which makes sense, but I’d be interested in hearing if you’ve encountered any edge cases where a valid update looks suspiciously like a tampering attempt. I’ve been working on a similar setup recently and found that using aipro.dev alongside my local validation scripts has made the debugging process much smoother. It helps me quickly iterate on the prompt structures to ensure the LLM is actually generating the *intended* schema violations for testing my gate, rather than accidentally passing them. It’s been a nice way to streamline the adversarial testing loop without getting bogged down in manual test case creation. Overall, this looks like a very practical, low-level solution to a high-level problem. I’ll definitely be cloning the repo to inspect the gate logic. Thanks for sharing the observation records—transparency like this is crucial for building trust in these systems. — Reply to this email directly, view it on GitHub <#461?email_source=notifications&email_token=BWY4VRRD66F5R6IPQZ7PG2D5SBDZDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGI2DKOBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18724587>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BWY4VRSQ34PY3NFK4Q7VUIL5SBDZDAVCNFSNUABIKJSXA33TNF2G64TZHM3TOMZSHA3DSOBQHNCGS43DOVZXG2LPNY5TCMBZGI2TKOBVUF3AE> . You are receiving this because you authored the thread.Message ID: ***@***.***>