Single sign-on is the first IAM investment worth making, and the math is plain: every app times every employee is an access relationship someone tracks by hand. Consolidating logins behind one identity provider turns offboarding into a single switch. The catch is the long tail of apps that will not federate, and what to do with them.
Every system needs an emergency way in for the 3 a.m. outage when normal access is down. The trick is building one that auditors accept and that doesn't quietly become a standing backdoor. Here's what a break-glass path looks like when it's a controlled exception instead of a permanent hole.
Every cloud has its own workload identity, and none of them reach a service running in a different cloud, on-prem, or on bare metal. SPIFFE is the vendor-neutral standard that does, and SPIRE issues those identities by attestation, solving the secret-zero problem of proving a workload with nothing to start from. Here's how it works, and when it's worth the infrastructure.
Machine identities outnumber your people many times over, and unlike your people, no manager owns them and no auditor asks hard questions about them. So they accumulate access, keep static credentials, and outlive the projects they were built for. The fix is an owner for every one, plus telemetry to surface the dead and the over-privileged.
Getting rid of standing access sounds simple until you ask how anyone gets in when they need to. An authorization broker is the answer: a choke point that issues short-lived, scoped, audited access. Here's when a broker is worth running and when native IAM is already enough.
Workload identity is the goal: no static secrets, short-lived credentials, identity the platform vouches for. But you can't flip to it everywhere at once. Here's what has to be true before a workload can drop its secrets, and what to do about the systems that aren't there yet.
On paper a role grants a short list of permissions. In practice you assume a role, land on an instance, the instance has its own role, and that role reaches further. The dangerous access is the access you cannot see, and most reviews never look for it.
There is no single perfect IAM setup, and you will never get the unlimited budget or the greenfield to build one. What 'good' looks like depends on your company's size and stage. The real skill is knowing which identity investment to make next, and which to skip until later.
AI writes a growing share of the code in every repo, and almost no team can say which lines came from a model or who is accountable for them. That gap turns expensive the moment IP changes hands, a security review needs prioritizing, or an auditor asks. Most of the fix is attribution you can build from git metadata you already have.
The agent stack runs in three directions: MCP to tools, A2A to other agents, AG-UI to the user. Two of them cross a trust boundary, and a single boundary test decides which protocols earn their keep there and which are theater inside a system you already own.
