The Layer I Refused to Build

By 2016 the obvious move was to build an end-to-end access control system. We had traction, a sponsor, and a real case for it. Users were hopping between three or four different products to get one thing done, and the experience was fragmented enough that consolidating it was the humane answer as well as the ambitious one.

I refused. It is the decision I'd defend hardest.

The company already ran dozens of access management systems doing role- and attribute-based control. Each had a team behind it with genuine expertise and real production responsibility. And that count understates it, because the data did not sit still — it flowed into and got copied across every adjacent first-party and third-party system that touched it, each with its own idea of what a permission was.

Building the unified one — ours, better, end to end — was what everybody expected and what the roadmap wanted.

Here is what we did instead, and it starts with taking four letters seriously.

Four jobs in one box

Access control has four jobs, and almost every product smushes them into one box.

Something has to know the facts a rule depends on: who works where, at what level, in which region. That's the policy information point. Something has to be the place a human actually writes the rule down. Policy administration point. Something has to decide, for this specific request, allow or deny. Policy decision point. And something has to actually stop you. Policy enforcement point.

Four names, four genuinely different jobs, and the entire industry ships them welded together and labeled "access control."

We took the second one. Only the second one.

What we were building was a policy ecosystem that stayed technology-agnostic at the top and became platform-specific at the bottom. A business owner writes one rule in their own vocabulary. A compiler turns it into whatever each system underneath actually speaks. Nobody authoring a policy needs to know which storage engine it lands on, and nobody enforcing one needs to know what a cost center is.

So: we'd interact with every decision point rather than replace any. We'd extend the existing trusted-attribute infrastructure with the business attributes nobody else had, and contribute those back. We'd let enforcement happen wherever the user actually touched data.

Staying out of the query path

And we would not sit in the query path.

That last one is worth being precise about, because it is the part people get wrong when I tell this story.

We absolutely ran on-call. The policy management system was ours, propagation had to be controlled, and some of that propagation was real time. What we never took on was the moment of decision itself. We were not between a user's request and the access check that answered it, which meant we never needed an SRE function and could never be the reason someone's query failed. Policies propagated ahead of the request, in batch and in real time. Owning propagation is a completely different operational burden from owning the request path, and choosing the first one kept a small team from having to become a large one.

Arriving as a subtraction

The second consequence is the one that actually kept the thing alive, and I didn't anticipate it.

Because one authored policy translated across many endpoints, the enforcement teams ended up managing fewer surfaces, not more. We arrived as a subtraction from their workload rather than an addition to it.

That mattered more than any feature we shipped. Every couple of years a new director or vice president would arrive and reassess everything, and the words policy and access management would read to them as an incursion into somebody's territory. We had that conversation, in some form, five or six times over a decade. The argument that never worked was ownership. The argument that worked every time was surface area.

A platform that tries to be authoring and decision and enforcement competes with everyone and is trusted by no one.

The gap we were filling exists because infrastructure teams own the primitives but not the business semantics. A finance director can say out loud who should see what. They cannot express it in coarse infrastructure terms, because the real rule involves integrations, exceptions, and the actual shape of how a business runs. We were domain experts who also understood the hooks into the technology. That gap was the entire product.

What the refusal cost

Now the costs, because a refusal is not free.

We could never ship anything that required being in the request path, and we sent people elsewhere for those capabilities. Staying at the authoring layer meant refusing the headcount and operational surface that come with owning runtime, so the team stayed structurally smaller than its influence. And I turned down offers to move into decision-point and enforcement-point roles, which made my own path less conventional than it might have been.

What it bought was horizontal scope and a position that generalized. The same separation that worked for security policy later worked for data quality, for fitness-for-purpose, and now for what an AI agent is permitted to run on. If we had built the unified access-control system, none of that would have transferred.

Decide what layer you are, write it down, and say no to the adjacent ones out loud and repeatedly. Being structurally incomplete is not a weakness to fix in a later version. It is what makes partnership possible with teams who could otherwise kill you.

The refusal was the product decision. Everything after it was execution.