Build the Fence Once, Inherit It Everywhere
Four fences is a lot to get right, and you do not get to get them right once. You get to get them right on every project, forever. So I stopped rebuilding the security and started inheriting it.
I spent four pieces on four fences. Assume the agent is hostile. Give it capabilities, not trust. Put three fences on the way in. Put one more on the way out.
That is a lot to get right. And this is the part I had to sit with: you do not get to get it right once. You get to get it right on every project. Every new agent, every new tool, every new system, forever. The day one of them ships with the tenant scope wired up almost correctly is the day you have a breach, and it will not be the system you were watching closely. It will be the small one nobody thought was risky.
So at some point I stopped rebuilding the fences and started inheriting them.
The security is a layer, not a lesson
The four fences do not live in each system. They live in one shared harness, and a new system inherits them by conforming to a few small contracts. It does not re-implement the security. It plugs in.
Four things a system does, four fences it gets for free.
It declares its tenants, and the harness provisions the per-tenant service accounts. That is fence one, and the system author wrote none of it.
It defines its tools as typed contracts, the same boundary models it would write anyway, and the harness wraps every one of them with authorization. That is fence three.
It reads data only through the scoped repository, and the tenant scope is injected underneath it automatically. That is fence two.
It returns its responses through the harness, and the egress filter runs on the way out. That is fence four.
The person building the system does not write the security. They conform to four contracts and inherit a hardened layer. That is the whole idea, and it took me longer than I would like to admit to see that this, not the individual fences, was the point.
One place to be right
Here is what centralizing actually buys you.
If a system that goes through the harness can leak across tenants at the access-control layer, that is a bug in the harness. You fix it once, in one place, and every system that inherits the harness is fixed at the same moment. It is not a patch you write four times and remember to ship to the fifth codebase, which is the version where one gets missed.
That “goes through the harness” is load-bearing, and I do not want to oversell it. The harness closes the infrastructure class of leak, the missing IAM boundary, the unscoped query. It cannot save a system that reaches around it with a background job or a raw export, or one that hands it the wrong tenant at the door. So the rule that comes with it is boring and strict: everything that touches tenant data goes through the harness, and you check that it does.
Reinvented security is how exactly one system out of ten ends up with the hole. A shared layer turns “did every project get this right” into “did the harness get this right,” and the second question has one answer you can actually go check.
Reuse before you build
I want to be honest about what the harness is made of, because if it were a giant new framework I would not trust it either.
Mostly it is wiring for things that already exist. Before writing any new security code, I walked the cheapest ladder that works.
Tenant scoping is row-level security in the database plus a thin scoped repository over it. A native feature first, not a homegrown filter.
Tool authorization is a decorator over the boundary models the tools already define, checking the caller’s capability against each call. The boundary model still only describes shape; the decorator is where authority gets checked. Not a new framework, a wrapper on the one already there.
Egress filtering slots into the same place in the pipeline as the inbound scanner, at the harness boundary, doing different detection work: watching for sensitive data going out rather than adversarial instructions coming in. Not a second system bolted on, a filter added to the path already there.
Per-tenant accounts are cloud IAM and a Terraform module. Not application code at all.
The harness is small because it mostly connects proven pieces. That is exactly why it is worth building once and trusting everywhere. A pile of clever new invention would not be.
Harden the worst case first
One more thing that mattered. You build this against your highest-risk system first, the one with the most sensitive data and the most exposure, and you let it be the thing that battle-tests the layer. Then every system after it inherits a layer already hardened against the hardest case, instead of discovering the gaps on its own. Not proven, hardened. A new system with different data flows still has to conform to the contracts and get checked against them. But it starts from a stronger baseline than a blank file and a good intention.
And because the harness holds only the security substrate, none of any one client’s logic, it is the clean kind of thing you could lift out and open-source someday. That is a later story.
The point was never the four fences
The four fences were the lesson. Building them once and inheriting them everywhere was the point.
It is the same idea the whole thing started from, just grown up. Guardrails belong in the tool, not the prompt. It turns out the tool is a thing you get to build a single time. Security you rebuild on every project is not security. It is a list of the incidents you have not had yet.