A control pattern that records which specific client applications a user has approved, along with the exact scopes granted. It prevents one authenticated client from inheriting the user’s trust for another client or another task.
Expanded Definition
Per-client consent is a client-specific authorisation control in which a user grants a named application only the scopes it needs, and that grant does not transfer to any other client, device, or workflow. In NHI and IAM practice, the concept sits between user consent, delegated access, and token issuance, so usage in the industry is still evolving and definitions vary across vendors.
What makes it different from ordinary session trust is the binding: the approval is tied to one client identity, one set of scopes, and usually one purpose. That is important in environments where autonomous software entities, APIs, and agents request access on behalf of a person. A well-implemented per-client consent model supports Zero Trust Architecture and least privilege because it prevents an approved app from quietly expanding its reach through reuse of the same authenticated user. NIST Cybersecurity Framework 2.0 reinforces the same governance direction by emphasizing controlled access and ongoing verification, while the Ultimate Guide to NHIs frames the operational risk of over-broad identity trust across non-human systems.
The most common misapplication is treating a single login or OAuth approval as blanket permission for all of a user’s connected clients, which occurs when consent screens, token exchange, or downstream APIs do not enforce client binding.
Examples and Use Cases
Implementing per-client consent rigorously often introduces more friction at onboarding and re-consent time, requiring organisations to weigh user convenience against tighter control over delegated access.
- A finance user approves a reporting app for read-only transaction scope, but a separate forecasting agent must request its own consent before it can access the same account.
- An internal helpdesk tool receives consent to read profile data, while a workflow automation client gets only ticketing permissions and cannot reuse the first client’s grant.
- A healthcare portal lets a patient authorise one prescription app for medication history, but a different reminder app must obtain a new, narrower grant.
- A machine-to-machine integration uses user delegation only for a specific approval workflow, while all other API calls remain blocked until the client’s own trust is established.
- In a modern consent review process, teams compare the stored grant against the actual client identity and scope list, aligning the workflow with the risk controls described in the NIST Cybersecurity Framework 2.0 and the NHI lifecycle guidance in the Ultimate Guide to NHIs.
These examples matter most where a single user interacts with many clients, because consent drift often appears after application sprawl, not during initial deployment.
Why It Matters in NHI Security
Per-client consent matters because it stops one approved client from becoming a trust multiplier across the identity plane. Without that boundary, a compromised application, agent, or integration can inherit the user’s approval and move laterally into other tools or scopes. That failure mode is especially dangerous in NHI environments where service-to-service access, delegated automation, and secrets handling already increase exposure. NHIMG research shows that 97% of NHIs carry excessive privileges, which means broad or reused consent can quickly turn a small approval gap into unauthorized access across multiple systems. The governance lesson is consistent with the NIST Cybersecurity Framework 2.0 and the Zero Trust emphasis in the Ultimate Guide to NHIs: every access path should be explicitly bounded, reviewed, and revocable.
Practitioners should treat per-client consent as a control for containment, not just compliance. It becomes most valuable when an audit reveals that one token, one approval screen, or one connected app has been reused far beyond its intended scope. Organisations typically encounter the consequence only after a client compromise or data access incident, at which point per-client consent becomes operationally unavoidable to address.
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 | Client-bound consent limits secret and token misuse across non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed and verified for each client relationship. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires explicit, continuous enforcement of access boundaries. |
Track and reassess each client grant to keep delegated access least-privileged.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
