A permission set is an additive access package in Salesforce that grants extra privileges without changing the base profile. It is the preferred way to extend access because it keeps the underlying role definition small and makes review and reuse easier across different users and functions.
Expanded Definition
A permission set is an additive access package in Salesforce that grants privileges on top of a user’s base profile. In NHI and IAM practice, it is best understood as a scoped entitlement bundle that can be assigned, reviewed, and revoked independently of the underlying role or profile. That makes it useful for separating job function from temporary or exception-based access.
Definitions vary across vendors, but the core security idea is consistent: permission sets should extend access without turning the base profile into a broad, hard-to-audit catch-all. This aligns with OWASP Non-Human Identity Top 10 guidance on limiting over-privilege and keeping entitlements visible. In NHI programs, the same pattern applies to service accounts, automation users, and AI agents when they need narrowly defined tool access. NHI Management Group also stresses that excessive privilege is one of the most common weaknesses in identity estates, especially where access is layered informally rather than governed as a distinct control surface, as discussed in Ultimate Guide to NHIs — Key Challenges and Risks.
The most common misapplication is using permission sets as a permanent substitute for proper role design, which occurs when teams keep adding exceptions instead of tightening the base profile.
Examples and Use Cases
Implementing permission sets rigorously often introduces review overhead, requiring organisations to weigh faster delegation against the cost of entitlement sprawl and approval tracking.
- A sales operations team receives a permission set for exporting reports without changing the standard sales profile for every user.
- A temporary contractor is granted a time-bound permission set for case management, then removed from the assignment at offboarding.
- An integration user gets a permission set that allows API access to specific objects while the base profile stays minimal.
- A release engineer is assigned a permission set for deployment-related administrative tasks during a change window, then the access is revoked afterward.
- A Salesforce automation account is given only the extra object and field permissions needed for a workflow, avoiding broad platform privileges.
In NHI governance, this additive model is especially important for machine-to-system access because it supports least privilege without creating a separate profile for every automation. That is why NHI Management Group research on key challenges and risks consistently treats entitlement sprawl as a visibility problem, not just a provisioning convenience. The OWASP Non-Human Identity Top 10 also reinforces that access should be explicit, reviewable, and bounded rather than accumulated by exception.
Why It Matters in NHI Security
Permission sets matter because they often become the hidden layer where excessive access accumulates. When teams cannot see which extras were granted, they cannot reliably answer who can reach what, which breaks access review, incident response, and offboarding for both human and non-human identities. This is especially important in environments where automation, service accounts, and agents interact with customer data, secrets, or administrative APIs.
NHI Management Group reports that 97% of NHIs carry excessive privileges, which makes additive access structures a governance issue rather than a convenience feature. If permission sets are not inventoried, time-bounded, and reviewed, they can undermine Zero Trust and create durable paths for lateral movement after compromise. For broader identity control design, practitioners should also align with the OWASP Non-Human Identity Top 10 so that additive access does not become an undocumented exception pipeline.
Organisations typically encounter the operational burden of permission sets only after an audit failure, privilege escalation, or breach investigation, at which point the term 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 | Addresses over-privilege and entitlement sprawl in non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Maps to managing access permissions and least-privilege enforcement. |
| NIST Zero Trust (SP 800-207) | Supports Zero Trust by requiring narrow, continuously evaluated access. |
Keep additive access explicit, reviewable, and minimally scoped to prevent privilege creep.
Related resources from NHI Mgmt Group
- When should organisations revoke an OAuth grant or third-party app permission?
- What is the difference between client identity and permission scope in MCP governance?
- Why do permission boundaries fail as a scale control for cloud access?
- What is the difference between SCPs and permission boundaries in AWS governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
