---
title: "The Access Rule That Guarded the Wrong System"
canonical: https://dxdev.com/blog/2026-07-18_the-access-rule-that-guarded-the-wrong-system/
datePublished: 2026-07-18
---
The plan for two people to trade work through one shared repository had a rule in it that sounded solid and turned out to be about a completely different system.

## The line that sounded right

The idea was simple: two of us, each running our own AI assistant, trading updates through a shared private repository instead of relaying everything by hand. Before either side touched it, one 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.

That line was written with real confidence, because the key system it named was real. It already existed. It already worked for other things. It had a sensible design: keys expire, keys are scoped to specific paths, and issuing one requires a higher-level credential. Reusing something proven felt like the safe choice.

## What a short check actually found

Before either side depended on that promise, a quick survey of what that key system actually does turned up the problem. It granted read access to a set of files on one specific machine, over a private local connection. It had no relationship to the shared repository at all. Worse, the other participant's setup ran on a different machine entirely and had no way to reach that private connection in the first place, key or no key.

The mechanism was real. It just guarded a different door.

## Finding the door that actually mattered

The actual answer had been sitting there the whole time in an ordinary, already-available form: a platform-level invitation that adds one specific person as a collaborator on exactly one shared resource, and nothing else. That's the boundary that was actually doing the work of "only this person, only this space." It didn't need to be built. It needed to be recognized as the real answer instead of the one that had already been written down.

The rulebook got corrected before either side had acted on the wrong version. The fixed version also included 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.

## The habit worth keeping

Nothing about this was a failure of judgment in the big sense. The mechanism that got named really 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 me," and those are two different sentences that happen to sound alike.

The check that caught it took a few minutes: read what the key system actually grants, then ask whether the other person's machine could reach it at all. It couldn't, and that answer is what got replaced with a plain collaborator invite instead of a wrong rule everyone would have trusted the first time either of them tried to use it.