Don't let Trust do the Job your Architecture should be Doing

Let's consider a five-person firm. Maybe a consulting firm (as was the build by

). Each consultant has a workspace of markdown files, client context, working notes, output logs, and Claude Code runs on top of it. The whole thing lives in one company repo. Everyone clones it, pulls in the morning, pushes at the end of the day. It works. I'd build it the same way.

Now ask what's stopping consultant three from opening client seven's folder. The honest answer is nothing. She just doesn't. There's a contract, there's training, she's a professional, and you know her. That's a real control and I'm not going to pretend otherwise.

But it's worth being precise about what's actually holding the system together, because it isn't the architecture. Git permissions stop at the repo boundary. Inside the repo, everything is readable by everyone who cloned it. The thing keeping client seven private is not a permission. It's a person.

That costs you nothing while it's true. The problem is that nothing in the system tells you the day it stops being true.

And it stops for ordinary reasons. You hire past the point where you personally know everyone. You bring a contractor in for one engagement. Someone leaves for a competitor. You sign a client whose contract says their data can't sit on personal devices. You take on a client who competes with a client you already have, and the gap between two folders suddenly needs to be an actual wall.

On the day one of those lands, you reach for the lever and find out what you really have. You remove the person from the repo. That stops their next pull. The clone they made three weeks ago is on their laptop, complete, and it stays there. Repo permissions govern who can get it. They don't govern who has it. That is distribution control, and most people think they bought access control.

The part I keep my eye on is calling this a big-company problem. It isn't a headcount thing. A fifty-person firm of salaried employees under proper contracts might be perfectly fine. A three-person shop with one contractor who also works for your competitor is not. The trigger isn't scale. It's the first time there's someone inside the system you wouldn't personally vouch for. That usually shows up with growth. It doesn't have to.

I'm not saying build for it now. Real containment means the agent runs somewhere the company owns with nothing cloning locally, and that's a hosted environment with auth, sessions, an isolated workspace per user, and someone maintaining the box. That should not be built that for five people who trust each other.

What I'm saying is name the trigger while it's cheap. Write down the condition that makes trust stop being enough in your setup. Then you'll notice the day you cross it, instead of finding out afterwards from the person who already left.

12 comments

Don't let Trust do the Job your Architecture should be Doing