Upkeep

I was an LFX mentee on CBOMkit where I helped to add support for finding cryptography assets in C and C++ code. Working on a tool that reads other people's code, I came to realize that a scanner is only as good as the reliability of its results. Then I saw the same problem with AI agents. Green tests are no proof of anything. For all 18 runs using four different Muse Spark models, the fix of an AI agent on a real Werkzeug upgrade passed all tests, but was still wrong. That problem is what upkeep is built around. It reads the old and new versions of a library without running them, finds the exact lines of your code that are going to be broken by the upgrade, and lets an AI agent edit only those lines. Then the code decides . Not the model . Upkeep runs your original code on the old library and the patched code on the new library, with the same inputs, in a Docker sandbox with no network. Anything else it rejects and passes the input and the line. 88 Werkzeug runs with the check on ended with 71 declined, 16 correct and 1 wrong. The agent is Muse Spark Open through Baseten. One try alone never fixed the hardest case (0 of 47), but when Upkeep returned the exact failing input, three tries fixed it 6 times out of 8. The `upkeep audit` doesn’t need AI or a key, and `--fail-on hard` can stop a risky upgrade in your CI. It gives an AI agent in software a new capability: to prove that its fix preserves the old behavior before anyone trusts it. Only Python, and so far only I have used it.