The identity gaps

Why is the set of principals the weak point, from departed accounts to cached decisions?

Account lifecycle. Every authorization model computes a yes/no answer over a set of principals, and assumes that set is current. It is not.

• Joining corrects itself: nobody can work without access, so someone fixes it at once.
• Leaving and moving do not correct themselves. An over-privileged account causes no error, raises no alert and blocks nobody.
• Movers are worse than leavers. A leaver at least causes an event (resignation). A mover collects the union of every role they ever held.

This is controls decay toward permissive with the clearest mechanism. The only remedies are ones that put cost on the permissive path: grants that expire, regular re-attestation (the manager confirms access again), and entitlements derived from an authoritative HR source and not granted by hand.

Service accounts. These are the majority of identities in any data platform and a poor fit for every access model. They have no owner who feels the cost of over-privilege, no natural expiry, credentials stored in configuration, and they are shared across pipelines because one account per job is friction. Sharing destroys attribution (the audit log names the pipeline, not a person). It also means the real privilege of a service account is the union of every job that uses it, which only grows. The structural fix is the credential-vending pattern from earlier: identity comes from workload attestation (the platform proves which job is running) and not from a stored secret, and it is scoped per pipeline and not per platform.

Separation of duties and two-person control. This is the only mechanism here that assumes the authorized person is the adversary. The idea is simple: make a harmful action require two independent principals. It is the only defence against a fully authorized insider that does not rely on detecting them afterwards. The price is delay on every covered action, so it is applied narrowly: key destruction, production data export, privilege escalation. The failure mode is degenerate approval, where the second person approves without looking. Then the control is just a log entry.

Break-glass. (Emergency access that overrides normal rules.) Sooner or later an incident will require access that nobody has. Either you design that path, or it is improvised under pressure with worse properties. A well-designed break-glass has three features: it is self-service (no approval queue during an outage), it is loud (it always alerts someone, and is not just logged), and it is time-bounded and self-revoking. The aim is not to prevent emergency access. It is to make emergency access expensive to use routinely, which is the difference between a control and a bypass.

Federation. (Trusting an identity provider you do not run, such as a university or partner company.) The right pattern is delegation of authentication with limiting of authorization: accept their statement of who the person is, never their statement of what the person may do. Two things fail in practice. Their account lifecycle becomes your stale-principal problem. Their compromise is your compromise, so the trust is a shared-fate dependency: if they fail, you fail.

Decision caching. Authorization sits on the hot path (it runs on every request), so the decision is cached, so revocation has a delay. This is the cache-invalidation problem with a security result. It is the same trade-off as time-to-live versus revocation in credential vending. The honest statement: your revocation SLA is your cache TTL, not your policy-update time, and most organizations do not know what theirs is. Example: if the policy engine caches "allowed" for 15 minutes, a fired employee can still read for up to 15 minutes after HR disables the account, however fast the HR update was.