# Decide whether permission inheritance needs explicit deny > Compare allow-only inheritance, deny precedence, and boundary objects through collaboration scenarios and operational tradeoffs. Canonical URL: https://www.devobs.io/articles/permission-inheritance-and-explicit-deny/ By: Jonah Reed Published: 2025-04-11T15:49:41.348Z Updated: 2026-09-05 Section: Architecture Use explicit deny only when the product has a clear, durable need to override inherited grants and users can understand the precedence. For most collaboration products, allow-only relationships plus explicit boundary objects are easier to explain, cache, and migrate. Once deny enters the model, it becomes part of every authorization decision and every access explanation. ## Test three real scenarios First, a company folder grants its engineering group read access, but one confidential document must exclude interns who belong to that group. Explicit deny expresses the exception directly. A boundary object can instead stop inheritance at the confidential subfolder and grant the intended group explicitly. The boundary is more verbose, but it makes the protected subtree visible. Second, a contractor gets project access directly while an organization policy denies all contractors. Which rule wins? AWS documents that an [explicit deny overrides an allow](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) across the policy types it evaluates. That is coherent in AWS IAM, but adopting similar precedence means every administrator must understand that adding an allow may have no effect because a distant deny still applies. Third, a user belongs to two groups: one allows editing, the other denies it. Deny precedence gives a deterministic answer, but group nesting makes the source hard to locate. Allow-only gives access, so sensitive exclusions must be modeled by changing membership, breaking inheritance, or granting a narrower positive group. Decide which administrative action matches how customers think about their resources. ## Account for implementation cost An allow-only check can often stop after finding one valid path. With deny precedence, the engine may need to search all applicable policies to prove that no deny exists. Cache keys and invalidation must account for both positive and negative relationships across ancestors and groups. Access explanations need to show the winning deny and the allows it defeated, otherwise users cannot repair policy. Cedar's [policy syntax documentation](https://docs.cedarpolicy.com/policies/syntax-policy.html) describes permit and forbid policies, with forbid taking precedence when authorization is evaluated. It also makes policy scope and conditions explicit. If your model includes deny, follow that clarity: define where a deny attaches, which actions and resources it covers, whether it inherits, and whether any boundary can contain it. Avoid a generic negative relation whose reach changes implicitly as the hierarchy evolves. Schema evolution is harder with negative permissions. Adding a parent to the hierarchy can introduce a deny into resources that previously allowed access. Renaming an action may leave old denies ineffective. Backfills should compute both newly allowed and newly denied subjects before activation, and rollout telemetry should distinguish changes caused by each. ## Prefer boundaries for confidentiality zones A boundary object says inherited grants stop here. It works well for a confidential folder, private project, or tenant partition because administrators can see and review the zone. Inside it, use positive grants. Explicit deny is a better fit when organization-wide prohibition is itself a first-class policy, such as preventing a regulated role from performing a particular action regardless of local grants. Write three customer stories involving overlapping groups and inheritance. For each, ask an administrator to predict the result and repair access. Then estimate evaluation paths, invalidations, and explanation data for allow-only, boundary, and deny-precedence designs. Choose the smallest model that represents the required prohibition without surprising its operators. ## Build explanation tests For every scenario, assert both the decision and a stable explanation: direct allow, inherited allow, boundary stop, or winning deny. Change group membership and parentage concurrently and verify cache invalidation. Explanations should use product concepts and identify the nearest repair point without exposing unrelated membership or confidential resource names. Test that adding a distant allow cannot bypass a deny and that deleting the winning rule reveals the next applicable decision predictably. Reviewed September 2026. ## Source references - -