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 don’t provide.
What changes for the CMM
- D2 L3 evidence should distinguish coupled vs decoupled NHIs in the inventory. Every coupled credential is a candidate for replacement with a decoupled alternative (e.g., SAS token → role-based access via Azure AD; storage access key → managed identity).
- D2 L4 rotation criterion must specify dependency-graph awareness for coupled credentials. Rotating without consumer mapping breaks production (cf. What Are Non-Human Identities? (Oasis Security) on operational rotation risk).
- D9 L4 dependency-mapping requirement 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 textbook coupled-identity case: the token is the identity, its permissions are baked in 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)