A non delegable permission is a capability the SaaS provider allows only to platform controlled roles and never exposes to customer created roles. It protects high risk actions such as platform support access or global configuration changes. Marking permissions as non delegable is a core guardrail for safe self service administration.
How Non-Delegable Permission Works
Non-delegable permissions create a hard boundary between tenant-administered roles and provider-controlled capabilities. They are typically reserved for actions that would let a customer alter the platform itself, widen support reach, or change global policy in ways that could affect many tenants at once.
In practice, this means the permission model is not just about who can do what, but also about who is allowed to delegate that authority onward. A permission can be technically powerful without being delegable, which is the point of the control.
- They usually sit above ordinary application roles and are only assignable to internal platform roles.
- They reduce the chance that self-service administration becomes self-service escalation.
- They preserve a provider-held trust boundary around sensitive operations.
Why The Control Matters
Non-delegable permissions matter because the same capability that enables efficient support can become a systemic exposure if it is exposed to customer-created roles. Once a high-risk action is broadly assignable, customers can unintentionally or deliberately propagate it across their own role hierarchy.
The control is especially important for permissions tied to support impersonation, tenant-wide configuration, billing or policy changes, and emergency break-glass style actions. Those are the places where delegation can turn a single administrative decision into a platform-wide trust problem.
NHIMG’s Ultimate Guide to NHIs is a useful reference for the underlying privilege and visibility problems that often appear when powerful access is not tightly bounded, while the OWASP Non-Human Identity Top 10 provides a broader control lens on overprivilege and secret-driven access paths.
Where It Shows Up In SaaS Design
Non-delegable permissions are common in SaaS products that expose role-based administration to customers but still need the vendor to retain certain powers. A good design separates customer autonomy from provider authority, so the customer can manage day-to-day administration without being able to create a role that crosses into platform governance.
That separation usually matters most in support workflows, tenant recovery, configuration changes with global side effects, and actions that touch audit integrity. It also affects how product teams design role templates, APIs, and admin consoles, because the UI may show a permission as available to the provider but deliberately omit it from customer role builders.
- Role inheritance should not accidentally reintroduce a non-delegable permission through nested templates.
- Documentation should clearly distinguish customer-administered rights from provider-only rights.
- Audit logs should preserve who exercised the capability, even when the end user never sees the permission surface.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Non-delegable permissions limit who can wield high-risk platform access. |
| NHI-03 — Lifecycle and Offboarding | Non-delegable permissions depend on tightly governed assignment and revocation paths. | |
| NHI-05 — Privilege and Access Boundaries | This term is fundamentally about keeping sensitive actions outside customer-delegable access. | |
| Recommendation — Restrict provider-only capabilities so customer roles cannot inherit or delegate them. Review and revoke platform-only permissions through a controlled lifecycle process. Enforce strict privilege boundaries between tenant roles and platform roles. | ||
| CIS Controls v8 | 6 — Access Control Management | Non-delegable permissions are an access-control boundary for sensitive administrative actions. |
| Recommendation — Limit administrative access to approved roles and remove customer exposure to platform authority. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | The concept governs which entities may be granted specific permissions. |
| Recommendation — Define and enforce authorization boundaries so only approved platform roles can use the permission. | ||
Practitioner Guidance
Governance implication: Treat non-delegable permissions as platform-controlled trust anchors, not just another role flag. If they can be copied, inherited, or approximated through another admin path, the control has effectively been weakened.
What to watch for: Review role builders, admin APIs, and support tooling for indirect ways to reproduce the same authority. The most common failure is not an obvious exposed permission, but an adjacent workflow that gives customers the functional equivalent of one.
For control design and boundary-setting, map the permission back to the smallest set of truly provider-only actions and keep customer roles one step removed from that authority. The safer the platform, the less often customers need to understand how close a permission came to being delegable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
