Where authorization decisions live, in one central service or in every service that owns its data, is an argument every platform team has and never settles. The policy, the evaluation, and the data a decision needs can each be centralized or not, independently. Here's the decomposition, what OPA, Cedar, and Zanzibar each centralize, and how to choose.
A service mesh proves one service is talking to another. It does nothing to carry the user's identity through the downstream calls, so deep in the call graph authorization falls back to 'it came from inside.' Here's how to carry the caller through every hop, and where the chain legitimately breaks.
A secure enterprise that issues no laptops and runs no VPN, where people work from their own devices, is buildable, but only by dropping two assumptions: that the device is trusted and that the network is. The endpoint becomes a window onto data that never lands on it, access goes per-app instead of per-network, and identity does the work the perimeter used to. Here's how it fits, and where you still need a managed machine.
Slow access is why environments end up over-provisioned: when a ticket takes three days, the rational move is to hoard every permission you might need and never give it back. Build paved roads instead, fast self-service access with automated approval, and people let go of what they don't need because getting it back is cheap. The environment locks down harder, and security gets the approval chain and audit trail for free.
Fine-grained authorization in a product starts clean: a Zanzibar-style relationship model answering who can touch which object. Then it grows new object types, new permissions, and the urge to layer in roles and groups, and the access graph never stops changing. The hard part was never the model; it's migrating it while it's live. Here's the problem, how to model it, and the open-source engines that help.
For decades, access has been decided once: you authenticate, you get a token, and the system trusts it until it expires, whatever changes in between. That model is ending. The Shared Signals Framework and CAEP move identity to a continuous decision, where a revoked session, a compromised device, or a risk spike reaches every app in near-real-time. Here's the shift, the standard behind it, and how far along it really is.
Across secrets, logins, and access, the same move keeps working: collapse a scattered, ungoverned surface into one governed point, because you can rotate, audit, and revoke one thing but not a hundred. The catch is that the one point turns critical, so the discipline is to defend it and keep a way in for when it fails. It's the pattern under most of the rest.
The IAM controls in this series prevent bad access; the SOC's job is to catch what gets through. A handful of identity detections do most of the work, chosen to be rare and meaningful enough not to drown the team, starting with the one every break-glass account needs: an alert the moment it is used.
Most access control protects systems: this database, that app, this bucket. It says nothing about the sensitivity of what is inside, so the same permission guards a marketing list and a table of social security numbers. Data-centric access ties the control to the data's classification, so protection follows the data across the systems that hold it. Here's how classification, labeling, and policy fit together, and why it's the hardest pillar to finish.
PDLC, SDLC, and the AI development lifecycle overlap more than their acronyms suggest, and forcing teams onto one rigid process to satisfy auditors kills the autonomy that makes them work. Standardize the control gates where evidence gets collected, let teams own the steps in between, and give AI-DLC its own branch only where it adds gates the others never had.
