Cyber Kimura Boundary Proof — Seeking Independent Technical Feedback

Developer Natalia Minkova released Cyber Kimura Boundary Proof, an open-source Python reference experiment with 23 tests, 15 mutation checks and four reproducible evidence examples probing whether an AI agent can still execute an action after its authorization has been revoked. In a follow-up exchange, a reviewer argued a single-process harness can pass while real workflows fail between two copies of authorization state, proposing a split harness with a known delay between replicas and a commit-time re-check stamped with the authorization version; Minkova said the prototype covers revocation and check-to-commit races against shared authoritative state, including a separate-process experiment, but does not yet model two replicas with delayed authorization propagation. The reviewer said fencing is the better default, with the caveat that revocation must advance the epoch at the commit point, and stated the scenario is an adversarial test case rather than an observed production failure.

I’ve released Cyber Kimura Boundary Proof , an open-source Python reference experiment exploring authorization continuity in AI-agent workflows. The question: Can an AI agent still execute an action after its authorization has been revoked? The project contains 23 tests, 15 mutation checks, and four reproducible evidence examples covering execution-time revocation, simulated identity and scope binding, and check-to-commit races. Try it yourself: git clone https://github.com/natalia-minkova/kimura-boundary-proof.git cd kimura-boundary-proof python3 evaluate.py Requires Python 3.12+ on a compatible Unix-like system. No API keys or third-party Python packages are needed. This is a synthetic reference experiment, not a production security tool or an automatic scanner for external agents. I’m looking for independent developers willing to reproduce the results and challenge the assumptions. I’d particularly appreciate feedback on whether these authorization-continuity scenarios reflect real challenges in your agent workflows. GitHub: GitHub - natalia-minkova/kimura-boundary-proof · GitHub https://github.com/natalia-minkova/kimura-boundary-proof Thanks for any technical feedback This is exactly the right question to make reproducible — and the one place a single-process version can pass while a real workflow still fails is between two copies of the authorization state, where the check reads one copy and the commit reads another that a revocation has not reached yet. Split the harness that way, with a short known delay between the copies, revoke inside the delay, and count how many actions still land; the close is to re-check at the moment of commit against the freshest copy and stamp each action with the version of the authorization it was approved under, so a commit carrying an older version refuses itself — and removing that re-check should turn the new test red, which is how you know it guards the commit and not just the check. Thanks — this is a useful distinction. The current Kimura prototype tests revocation and check-to-commit races against a shared authoritative state, including a separate-process experiment. It doesn’t yet model two replicas with delayed authorization propagation. Your proposed scenario would expose a different failure mode: execution based on a stale authorization version, even when the local check appears correct. One question I’d like to clarify: would you require a linearizable authorization check at commit, or use version/fencing semantics to reject actions approved under an older authority epoch? I’d also be interested in whether you’ve encountered this failure mode in an actual agent workflow or are proposing it as an adversarial test case. Fencing is the better default, with one honest limit: a lagging commit copy cannot tell ‘no revocation happened’ from ‘the revocation has not arrived yet,’ so fencing closes the hole only if revocation itself advances the fence at the commit point — bump the epoch there first, stamp every approval with its epoch, and have the commit point keep the highest epoch it has seen and refuse anything older, so ordinary commits stay local and the strong step is paid only on revocation, not on every action. For an irreversible action whose revocation cannot reach the commit point that way, require the authoritative re-check at commit instead. And to your second question, plainly: this is an adversarial test case drawn from the replica split, not a failure I am claiming to have watched happen — its value is that it would fail the same way whether or not anyone has met it in production yet. I agree that fencing only provides the intended guarantee when the commit point has reliable visibility of the relevant epoch advancement. Otherwise, a stale replica can continue accepting an older authorization state. It’s also helpful to know this is a proposed adversarial scenario rather than an observed production incident. I’m keeping it as a candidate test case while investigating similar authority-continuity questions in autonomous systems, particularly where connectivity is intermittent Intermittent connectivity is where that limit bites hardest, because a cut-off commit point cannot see the epoch move at all — so give each approval a short life as well as its epoch: stamp it with an expiry the commit point checks on its own clock, refuse anything expired even when its epoch still looks current, and make renewal the cheap repeatable step while revocation stays final. Test it by partitioning the two copies, revoking while they are apart, and holding the partition longer than the approval’s life: nothing approved before the revocation should land afterwards, and shortening that life should shrink the stale window to exactly the life you chose, which is how you know the bound itself, not luck, is doing the work. That’s a really good point. I hadn’t thought enough about what happens when the drone loses connectivity and can’t receive the revocation. I’m starting to look at this from the drone security side, where losing authorization mid-mission raises another question: what should the drone actually do to stay safe? I think that’s an interesting area to explore. Thanks for sharing your thoughts, I really appreciate it That question has a clean answer if you settle it while the drone is still connected: let the approval itself carry the fallback — alongside its expiry, stamp in the one safe action to take when the approval lapses hold position, return, or land, whichever fits the mission , so losing the link never leaves the drone improvising, it just runs the instruction it already has. The test is the partition you already have: cut the link mid-mission and let the approval expire — the drone should perform exactly the stamped fallback, and a renewal that arrives late should start a fresh approval rather than reviving the expired one. That’s an interesting way to approach it — defining the fallback before the drone loses connectivity, rather than trying to decide what to do afterward. I especially like the point about late renewal not automatically restoring expired authority. I’m now looking into what ArduPilot and PX4 already support, and whether there’s a meaningful gap in how these scenarios are tested. Thanks for taking the time to think this through with me. It’s been really helpful