SaSame

We spent part of this week chasing a class of bug that's annoying precisely because it's intermittent: audit evidence files disappearing with ENOENT, no obvious pattern at first glance. The proximate cause was a race in the evidence-write path — under certain conditions the write would target a path that assumed a branch state that had already moved on. The fix touched two things: repairing the write path itself so it doesn't assume stale branch context, and adding a new tool, git_branch_sync_main, so agents have an explicit way to reconcile local branch state with main before evidence gets written against it (#2660/#2662). While debugging this we also went back through an earlier incident we'd flagged but not fully closed out: a checkpoint-api-current symlink that had caused a deploy-tool failure back in #2615. We wrote up the root cause properly this time instead of leaving it as a one-line postmortem note. Turns out symlink resolution assumptions and evidence-path assumptions are cousins of the same problem — code trusting that "current" state means what it did a moment ago. Separately, and not directly caused by this, our CTO finalized full-system audit coverage (#2687). Good timing, honestly — coverage without a reliable evidence chain underneath it is mostly theater. Our autonomous agents use this evidence for deploy gating, so a missing file isn't just an annoyance, it's a gate that either fails open or fails closed for the wrong reason. None of this is glamorous work. It's the kind of thing you only notice when it's broken. But it's exactly the layer we're building SaSame on top of, so it has to hold. #buildinpublic #MCP #AIagents

Found a hole today: a high-impact action could route around its dedicated wrapper and go through a generic execution path instead, which meant it skipped the extra scrutiny that wrapper exists to enforce. For context, in SaSame some actions are marked high_impact and are supposed to only run through a specific wrapper — a narrower code path with its own checks, logging, and constraints on top of what the generic path does. The gap was that nothing actually stopped a high-impact action from being invoked generically instead. The wrapper wasn't broken, it was just optional in practice. That's effectively a laundering path: the sensitive act still happens, but it happens under the identity of a boring, low-scrutiny call. The fix was to stop treating "use the wrapper" as a convention and start enforcing it as a gateway rule: high_impact_requires_dedicated_wrapper. Any high-impact action attempted outside its designated wrapper now gets rejected at the gateway, before it can execute through the generic path at all. The annoying part was downstream of the fix, not the fix itself. We regenerate an automation-lifecycle-registry that an audit check validates against, and tightening the enforcement rule meant the registry's expected shape changed. Had to regenerate it to get the audit check passing again — a reminder that closing a policy gap isn't just "add the check," it's also making sure everything that asserts against the old, looser reality gets updated to the new one. Small fix, but the kind of gap that's easy to miss because nothing was technically broken — the wrapper worked fine whenever it was used. The bug was that using it wasn't actually required.

We found a gap this week where a high-impact action in the MCP Factory could, in theory, skip its dedicated wrapper and go through a generic call path instead — same underlying action, but without the extra scrutiny that wrapper is supposed to force. The wrapper exists specifically for actions we've flagged as high-impact: it adds checks that the generic path doesn't. But nothing was actually stopping the generic path from being used to invoke the same action. Nothing was broken in the sense of throwing errors — it just meant a sensitive act could be laundered through a route that looked ordinary, quietly skipping the scrutiny it was supposed to require. We closed it by enforcing high_impact_requires_dedicated_wrapper as a gateway-level rule rather than something the wrapper itself was expected to self-police. If an action is marked high-impact, the gateway now checks that it's arriving through its dedicated wrapper before it goes any further — the generic path can't carry it anymore. That change also meant the automation-lifecycle-registry, which our audit check reads against, was now out of sync — it didn't reflect the new enforcement rule. We regenerated it so the audit check passes against the actual current state instead of a stale one. Nothing dramatic here, just the kind of gap that's easy to miss because everything still works and nothing looks wrong — until you go looking for the path that shouldn't exist. #buildinpublic #MCP #AIagents