Identity, policy, and the trust boundary

A long-running platform program had a recurring symptom: every product team was rebuilding small pieces of the same identity, permissions, and policy logic. The cost showed up as drift, subtle authorization bugs, and slow feature delivery in regulated surfaces.

The framing

The interesting question was not “what library do we standardise on?” but where does the trust boundary actually live? Once that was named clearly, the rest followed.

We reframed identity and policy as a small, opinionated platform surface — owned, versioned, observable — and pushed product code to consume it rather than reimplement it.

What changed

• A single token model with explicit scopes and a clear refresh contract.
• Policy as data, evaluated at the boundary, with a tiny embeddable evaluator.
• A typed client SDK that made the right thing the easy thing.
• An audit stream that turned authorization into something we could read, not guess at.

Tradeoffs

The system absorbed real complexity so product code didn’t have to. That meant slower change at the platform layer, deeper review, and explicit migrations. We chose that intentionally: the cost of a bug here is paid by every team.

Outcome

Feature teams stopped writing auth code. Sensitive surfaces moved faster, not slower. Most importantly, the system became legible — engineers could read it and reason about it instead of reverse-engineering precedent.