The practice of including only the identity attributes required for a specific access decision. In API security, claim minimisation reduces unnecessary data exposure, simplifies token review, and lowers the risk that broad identity context becomes a hidden authorisation dependency.
Expanded Definition
Claim minimisation is the discipline of issuing or presenting only the identity attributes needed for a specific access decision. In NHI security, that usually means reducing token scope, suppressing nonessential claims, and avoiding identity context that is convenient for applications but unnecessary for authorisation. The goal is not to hide identity, but to limit what travels with it.
Definitions vary across vendors because the term sits between IAM design, token engineering, and privacy engineering. In practice, claim minimisation supports NIST Cybersecurity Framework 2.0 principles for access control and data minimisation, especially where service-to-service trust is built on JWTs, OIDC claims, or federated identities. It is most effective when paired with explicit policy at the enforcement point rather than embedded assumptions in the token itself.
The strongest implementations treat claims as decision inputs, not as a general-purpose profile of the actor. That distinction matters for agents, service accounts, and other NHIs that often accumulate broad identity context over time. The most common misapplication is leaving high-value claims in every token because downstream services might need them later, which occurs when teams optimise for developer convenience instead of least privilege.
Examples and Use Cases
Implementing claim minimisation rigorously often introduces integration friction, requiring organisations to weigh simpler token reuse against tighter control over what each service can learn.
- A payment microservice receives only tenant ID, role, and audience claims, while profile details are removed to reduce exposure if the token is logged or replayed.
- An AI agent calling a model tool chain is issued a narrow token for a single workflow, rather than a broad identity bundle that could be reused across unrelated tools.
- A federated workload identity uses short-lived assertions with only the claims required for trust evaluation, while richer attributes remain in the source identity system.
- Security teams reviewing incidents often compare claim sets to the attack patterns described in the DeepSeek breach because exposed or over-shared identity context can become a reconnaissance aid after a compromise.
- Designers align claim release rules with the NIST Cybersecurity Framework 2.0 so that services receive only the attributes needed for authentication, authorisation, and audit.
In mature environments, claim minimisation also reduces the blast radius of token theft, because a stolen token reveals less about the broader identity fabric. That matters most in distributed systems where claims are copied into caches, traces, and logs far beyond the original request path.
Why It Matters in NHI Security
Claim minimisation matters because broad identity context often becomes an invisible dependency. When an access path works only because a token carries extra claims, the system is no longer using explicit policy cleanly; it is relying on accidental privilege embedded in identity data. That makes governance harder, incident response slower, and privilege review less reliable. It also increases the chance that sensitive attributes are exposed to services that never needed them.
The risk is amplified in AI and automation pipelines, where a single NHI may authenticate many times per minute and pass through logging, orchestration, and inspection layers. NHIMG research on DeepSeek breach shows how exposed identity-related data can quickly become part of a larger compromise narrative, while the wider secrets landscape shows that organisations still struggle with control consistency. In The State of Secrets in AppSec, organisations maintain an average of 6 distinct secrets manager instances, and the average estimated time to remediate a leaked secret is 27 days.
Organisations typically encounter the impact after a token leakage, authorization failure, or audit finding, at which point claim minimisation becomes operationally unavoidable to restore least privilege and reduce exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Limits overbroad identity claims and reduces secret exposure in NHI flows. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be enforced with least-privilege attribute release. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust prefers minimal, just-in-time trust signals for each request. |
Issue only claims needed for each NHI access decision and review token contents routinely.
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org