AllPrincipals consent is a tenant-wide grant that allows an application to act across all users in an organisation. It is powerful because one approval can replace many individual decisions, which makes it a high-risk control point when consent is writable by compromised identities.
Expanded Definition
AllPrincipals consent is a tenant-wide permission grant that authorises one application to act across all users in an organisation. In practice, it is broader than single-user approval because the consent boundary is the tenant, not the individual account. That distinction matters in EU General Data Protection Regulation (GDPR) environments, where access scope and data minimisation are central governance concerns.
In NHI and IAM operations, AllPrincipals consent is often used for productivity, collaboration, monitoring, or automation apps that need read or action rights across a directory. Definitions vary across vendors on how they label consent grants, admin approval, and delegated access, so practitioners should focus on the effective privilege outcome rather than the UI wording. It should be treated as a high-impact control because the application is not merely linked to one identity, it inherits organisation-wide reach until revoked or narrowed.
The most common misapplication is treating tenant-wide consent as a routine onboarding step, which occurs when approvers do not evaluate the app's full data access scope.
Examples and Use Cases
Implementing AllPrincipals consent rigorously often introduces governance friction, requiring organisations to balance user convenience and automation speed against broad blast radius and review overhead.
- An internal reporting app is granted tenant-wide read access to mailboxes so it can generate executive dashboards without per-user prompts.
- A security monitoring platform receives organisation-wide directory permissions to detect risky sign-ins and posture changes across all users.
- A workflow automation tool is approved once for all principals, allowing it to create tickets or notify teams based on enterprise events.
- A delegated admin model is paired with consent review so only a narrow set of trusted apps can receive tenant-wide grants.
- For governance context, NHI teams often pair this control with guidance from the Ultimate Guide to NHIs and platform-specific consent policies.
When the app scope is tied to protected data handling, the consent decision should also be tested against external authority guidance such as EU General Data Protection Regulation (GDPR) to confirm that tenant-wide processing is justified and documented.
Why It Matters in NHI Security
AllPrincipals consent becomes an NHI security issue because the application is effectively another non-human identity with delegated reach. If that consent is granted too broadly, attacker-controlled code can inherit access across the tenant without needing to compromise many individual accounts. NHIMG notes that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which reinforces how quickly overbroad grants can become the default rather than the exception.
Tenant-wide consent also complicates offboarding, rotation, and incident response. One overlooked approval can survive long after the original business need has changed, especially when no one tracks who requested it, who approved it, and whether the app still requires broad access. This is why consent governance belongs alongside secret protection and lifecycle controls, not just application onboarding. The same governance pressure appears in broader NHI risk discussions from Ultimate Guide to NHIs, where visibility and privilege management are treated as core resilience issues.
Organisations typically encounter the operational impact only after a suspicious app token is abused or an unexpected data access event is traced back to a tenant-wide grant, at which point AllPrincipals 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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Tenant-wide consent creates broad NHI privilege that OWASP flags for strict governance. |
| NIST CSF 2.0 | PR.AC-4 | Consent scope maps to managing access permissions and least privilege across the environment. |
| NIST SP 800-63 | Identity assurance supports the trust placed in admins who approve broad delegated access. | |
| NIST Zero Trust (SP 800-207) | Zero Trust rejects implicit broad trust, which tenant-wide consent can otherwise create. | |
| NIST AI RMF | Broad delegated access is an AI risk management concern when agents or apps act on many users. |
Document, approve, and periodically revalidate tenant-wide app access as part of access control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 15, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
