Identity-Credential Coupling
A property of certain Non-Human Identities where the credential string IS the identity — the authentication material is not separable from the principal it represents. Rotation cannot be performed independently of identity change.
The framing comes from Oasis Security:
“Special considerations arise in scenarios where identities are inseparable from the authentication string, as seen in Storage account access keys, Shared Access Signatures (SAS) tokens, and API keys for Software as a Service (SaaS) applications like Snowflake. In such instances, the authentication method encapsulates permissions configuration, complicating IAM and IGA.”
Coupled vs decoupled identity-credential pairs
| Decoupled (rotatable) | Coupled (rotation = identity rotation) |
|---|---|
| Service Principal with separate client secret | Storage Access Keys |
| OAuth client_id with separate client_secret | SAS tokens |
| Username + password | Snowflake-class API keys |
| SPIFFE SVID + private key | Personal Access Tokens (PATs) where the token IS the access |
| IAM role assumed via short-lived STS credentials | Shared bearer tokens with no separate principal record |
For decoupled pairs, the Credential Proxy Pattern for AI Agents works as designed: the proxy holds the secret, the agent never sees it, rotation is an internal concern. For coupled pairs, the proxy can intermediate access but cannot prevent the underlying identity from changing on rotation — every consumer must be updated.
Why this matters operationally
Three consequences flow from coupling:
- Rotation breaks consumers. Every system that has the old key wired in must be updated atomically. This is why SAS tokens and storage access keys are rarely rotated in practice — the operational risk is high.
- Permissions are encoded in the credential. A SAS token’s permissions are defined at issuance; you cannot adjust scope without issuing a new token (= new identity). This conflicts with continuous-least-privilege programs.
- Audit becomes harder. A rotated SAS token is observably different from the prior one; correlation across rotation events requires explicit lineage tracking that most systems do not provide.
What changes for the CMM
The D2 Identity deep dive folds coupling directly into the identity ladder, and the RA lists coupled-credential migration as an Identity-plane capability:
- D2 L3 inventory must distinguish coupled from decoupled NHIs. Every coupled credential is a candidate for migration to a decoupled alternative — SAS token or storage access key → Azure Managed Identity + RBAC; long-term cloud keys → AWS IAM Roles Anywhere (X.509 → short-lived STS) or GCP Workload Identity Federation.
- D2 L4 keeps an active migration plan off coupled credentials and ties rotation to a documented consumer-dependency map; rotating a coupled credential without one breaks production (cf. What Are Non-Human Identities? (Oasis Security) on operational rotation risk).
- D9 L4 dependency-mapping applies acutely here: before rotating any coupled credential, the consumer graph must be known.
Real-world consequence
What Are Non-Human Identities? (Oasis Security) cites the Microsoft AI Storage Breach — a misconfigured SAS token exposed 38TB of internal data. SAS tokens are a canonical coupled-identity case: the token is the identity, its permissions are fixed at issuance, and rotation requires updating every consumer.
Relations
- Concept anchor: Non-Human Identity (NHI) (parent concept)
- Defensive control: Credential Proxy Pattern for AI Agents (works for decoupled, partial for coupled)
- Practice: NHI Governance for AI Agents (rotation cadence varies by coupling)
- Source: What Are Non-Human Identities? (Oasis Security)