Identity and privilege chains: follow the credentials, not the arrows

Most architecture diagrams draw calls: the web app calls the orders service, the orders service writes to the database. Attackers care about something else. They ask which credentials they can obtain, and what each credential lets them become next. A developer laptop holds a cloud access key; that key can assume a deployment role; that role can read the cluster's secrets; one of those secrets is a database password. None of those steps appears as an arrow on the diagram, yet together they connect a stolen laptop to every customer record.

That sequence is a privilege chain. Mapping your chains is one of the highest-value exercises in security architecture, because the weakest link in a chain sets its strength while the most powerful permission at its end sets the damage.

A privilege chain is any path along which one identity can act as, or obtain the rights of, another. The links take a few familiar forms:

• Assumption: a principal assumes a role, impersonates a service account or uses a break-glass account.
• Exchange: one token is traded for another, such as a CI system's OIDC token for a short-lived cloud session, or a user token exchanged for a downstream service token.
• Possession: a workload can read a secret that is itself a credential: a database password, an API key, a signing key.
• Control: an identity can change what another identity may do, by editing a policy, binding a role, or passing a role to a new compute resource. This is the link most often missed, because it grants nothing directly.
• Delegation: a service, support tool or AI agent acts on a user's behalf, carrying some of that user's authority.

Machines usually outnumber people by a wide margin in these chains. Pipelines, functions, containers and integrations each hold an identity, and each is a possible first link.

Start from the data or capability you would least like to lose, then walk backwards: which identities can reach it, and what can reach those identities? Draw both the chain you designed and any chain that exists by accident.

For each identity on the map, record five facts: how it authenticates, what it can assume or exchange into, whether its privileges are standing or granted just in time, how long its credentials live, and who can change its permissions. The last fact finds the control links.

Across cloud and SaaS estates, the same weak links keep turning up:

• Long-lived keys. Access keys and service account keys that never expire, copied into CI variables, developer machines or wiki pages.
• Over-trusting federation. An OIDC trust policy that accepts any repository in an organisation, any branch, or any workflow, so a pull request from a fork can obtain the deploy role.
• Permission to grant permissions. Roles that can edit policies, create role bindings or pass a powerful role to a new function. Holding one of these is equivalent to holding the most powerful role it can grant.
• Shared identities. One service account used by five workloads, so compromising the least protected one yields the rights of all five.
• Tokens without an audience. A token accepted by any service in the estate lets one compromised service replay it against the others.
• The confused deputy. A trusted service performs an action for a caller using its own broader authority, because it never checked whether the caller was entitled to that resource. Cross-account roles without an external identifier are the classic cloud example.
• Forgotten emergency access. Break-glass accounts with standing administrator rights and no alerting on use.

You cannot remove chains; systems need delegation to work. You can make every link short, narrow and observable.

1. Prefer short-lived, federated credentials. Workload identity and OIDC federation instead of stored keys, with sessions measured in minutes.
2. Bind trust tightly. Federation conditions should name the exact repository, branch or environment and audience. Review them like firewall rules.
3. Down-scope at every exchange. When one token is exchanged for another, the new token should carry fewer rights and a specific audience. OAuth token exchange can also record the original subject, so downstream services know who the request is really for.
4. One identity per workload. Never share service accounts between deployables, and never reuse production identities in other environments.
5. Treat control permissions as administrative. Restrict policy editing, role binding and role passing to a small, audited set of identities, and keep them away from workloads.
6. Elevate just in time. People get elevated rights for a task, with approval and expiry, rather than standing administrator roles.
7. Log every link. Role assumptions, token exchanges and policy changes should land in one place where an unusual chain can be noticed.

AI agents add a new kind of link: a model choosing actions with an identity's authority. The rules above still apply, with one addition. The agent's instructions can be influenced by any text it reads, so its identity should be scoped to the task rather than inheriting everything its user can do, and the actions that matter most should require a person to approve them. Our guide to how AI can help your existing architecture covers where that line sits.