Additive permissions means a user can accumulate access rights from multiple groups or assignments. In Confluence, this can create broader visibility or export capability than expected if group membership is not carefully governed. The model is efficient, but it demands disciplined administration to avoid accidental overexposure.
How Additive Permissions Work
Additive permissions are built on accumulation, not replacement. A person or process can inherit access from several sources at once, so the effective permission set is the union of all assigned rights unless a compensating control removes or overrides them.
This model is common in collaboration platforms, IAM systems, and enterprise applications because it reduces administration overhead. It also means the final access outcome is not visible from one role or group in isolation, which makes permission reasoning harder for reviewers and owners.
Why Additive Permissions Create Oversight Challenges
The main challenge is that access growth can be gradual and unintentional. A user may begin with limited access and later accumulate broader read, export, admin, or sharing capability through group membership, project assignment, or inherited policy.
That makes reviews more difficult because the risky condition is often the combination, not any single grant. Additive models also increase the chance that inherited access lingers after a user changes role, joins a new team, or no longer needs a former privilege path.
Where Additive Permissions Commonly Appear
Additive permissions show up in group-based authorization, role stacking, inherited application permissions, and systems that merge entitlements from multiple directories or workspaces. They are especially important in environments where access can be granted both directly and indirectly.
In practice, the issue is not limited to human users. Service accounts, integrations, and automated workflows can also accumulate permissions from multiple assignments, which makes the resulting access profile more difficult to reason about and easier to overextend.
When additive access is combined with broad export, sharing, or administrative functions, the impact can extend beyond what the original grant appears to allow. That is why access intent, effective permissions, and entitlement ownership all need to be interpreted together.
Additive Permissions Versus Explicitly Scoped Access
Additive permissions differ from models that replace prior access, because the system keeps adding rights unless a specific revocation or boundary is enforced. This is efficient for scaling administration, but it can also hide privilege creep when multiple teams manage different parts of the same user’s access.
The practical distinction matters during audits and incident reviews. A single assignment may look harmless, yet the effective permission set can still be excessive because earlier grants remain active. The strongest reference point for understanding this control problem is the OWASP Non-Human Identity Top 10, which treats overprivilege and secret governance as recurring failure patterns in accumulated access.
Risk and Threat Considerations
Additive permissions can create silent privilege expansion when multiple low-risk assignments combine into a high-impact access path. That matters because the effective permission set may enable unintended visibility, export, or destructive action even when no single grant looks extreme on its own.
Failure mechanism: Access is accumulated across groups, roles, or assignments without sufficient review of the effective permission set, allowing excessive rights to persist after changes in job function or ownership.
Impact: The result can be overexposure of sensitive data, broader-than-intended administrative capability, easier lateral movement after compromise, and a larger blast radius when a user, integration, or automated account is misused.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Additive access can produce excess effective privilege through stacked grants. |
| NHI-01 — Improper Offboarding | Accumulated access must be removed when users or accounts no longer need it. | |
| Recommendation — Review cumulative entitlements to detect and reduce overprivileged accounts and workloads. Revoke inherited and direct access paths promptly during offboarding and role changes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Effective permissions should be limited to the minimum needed despite additive grants. |
| AC-2 — Account Management | Additive permissions depend on account and entitlement lifecycle governance. | |
| AC-3 — Access Enforcement | Authorization must enforce the combined permission outcome, not just individual grants. | |
| Recommendation — Enforce least privilege by regularly validating the final effective access set. Manage account and entitlement changes so accumulated access stays justified. Apply access enforcement rules to the full effective permission set. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Additive permissions are an identity and entitlement governance issue. |
| A.5.18 — Access rights | The term directly concerns how access rights accumulate and should be controlled. | |
| Recommendation — Maintain accurate identity records that reflect all active access relationships. Review access rights for cumulative privilege and remove unnecessary combinations. | ||
Practitioner Guidance
Why practitioners should care: Additive permissions are easy to administer at scale, but they require careful entitlement hygiene because the effective access outcome is what matters, not the individual grant in isolation. Treat permission accumulation as a lifecycle problem, not just an onboarding or role-design issue.
Common misunderstanding: Teams often assume that a “small” group or role cannot create meaningful exposure by itself. In additive systems, the real risk is overlap, so a benign-looking access change can still tip the user into overprivilege.
Practitioner takeaway: Review effective permissions, not just assigned permissions, whenever access is granted, changed, or inherited.
Related resources from NHI Mgmt Group
- Why do exclusion rules create different authorization risk than additive permissions in Zanzibar-style systems?
- How should security teams manage permissions for AI agents?
- Why is defining permissions important for AI agents?
- What is the difference between visible permissions and effective access in AD?
