The Safeguard We Trusted Guarded a Different Door

Two of us were about to trade work through one shared private repository, each with our own AI assistant, and the plan had one line in it about access that sounded solid. It turned out to be about a completely different system.

The line in the rulebook

The idea was simple. Instead of relaying every update by hand, the assistants would pass work back and forth through a shared private repository. Before either side touched it, a line in the shared rulebook described how access would work: a scoped, time-limited key, issued through an existing control system, good for this one shared space and nothing else.

I wrote that line with confidence, because the key system it named was real. It already existed and already worked for other things. Its design made sense: keys expire, keys are limited to specific paths, and issuing one requires a higher-level credential. Reusing something proven felt like the safe choice.

What a short check found

Before either side depended on that promise, we took a quick look at what the key system actually does. It grants read access to a set of files on one specific machine, over a private local connection. It had no connection to the shared repository at all. Worse, the other person’s setup ran on a different machine and had no way to reach that private connection, key or no key.

The mechanism was real. It guarded a different door.

The door that mattered

The answer had been available the whole time in an ordinary form: a platform-level invitation that adds one specific person as a collaborator on exactly one shared resource, and nothing else. That boundary does the work of “only this person, only this space.” Nobody had to build it. We only had to see it as the answer, instead of the option already written down.

We corrected the rulebook before either side had acted on the wrong version. The fixed version also got a plain rule for what happens when both people’s work has moved forward at the same time: pull in the other side’s changes first, combine them, and never overwrite what the other person did without looking at it first.

Real safeguard, wrong target

The key system was a legitimate access control, doing exactly what it was built to do, somewhere else. The mistake was treating “this is a real, working safeguard” as the same claim as “this safeguard protects the thing in front of us.” Those are two different sentences that happen to sound alike.

The check took a few minutes. We read what the key system grants, then asked whether the other person’s machine could reach it at all. It couldn’t. So the rulebook now says to send a plain collaborator invite, in place of a rule that both of us would have trusted until the first time either of us tried to use it.

dxdev LESSON · paste into your AI coding agent
LESSON: A real safeguard is only relevant if it protects the thing you're actually sharing
SOURCE: dxdev.com/blog/ai-relay-via-shared-vault
WHAT HAPPENED: A collaboration plan for two people to trade work through a shared repository named a specific access-control mechanism as the thing that would keep the sharing scoped and safe. That mechanism was real and already used elsewhere, but a short survey found it granted access to a different local system entirely, one the other participant's machine could not reach at all. The actual authorization boundary turned out to be a separate, already-available mechanism: a platform-level collaborator invite scoped to exactly one shared resource. The plan was corrected before anyone relied on the wrong claim, and a non-destructive recovery rule (fetch, merge, retry, never force-overwrite) was written in alongside it.
THE RULE: Before writing an access-control promise into a shared agreement or automation, verify that the named mechanism authorizes the exact resource being shared and that every participant can actually reach the system that enforces it. A real, working security feature can still be the wrong one for the job.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. For each claimed access-control mechanism in the docs or config, confirm it authorizes the exact resource being shared, not a similarly named or adjacent one.
  2. From every participant's actual environment, confirm real reachability to whatever system enforces the claimed permission.
  3. Confirm shared-access instructions name the real authorization path and include a non-destructive recovery rule for when two sides' work has diverged.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.