The Gold Standard of Zero Trust | Combining Permission Grants Without Treating a Boundary as Another Grant

A request needs more than the word read or administrator. Identify the subject, operation, resource and relevant conditions. For this teaching model, one fictional technician is requesting operations on maintenance records for rooms A and B. Hold the subject and context fixed initially so that we can inspect six distinct requests.

Call r1 reading room A’s record, r2 updating room A’s record, r3 reading room B’s record, r4 updating room B’s record, r5 scheduling room A’s maintenance and r6 scheduling room B’s maintenance. The finite universe U contains exactly these six labelled requests.

The labels are bookkeeping devices, not API names or a recommended permission scheme. Their purpose is to keep each action-resource relationship intact. A permission to update one room’s record does not become a permission to update every room simply because the operation name is unchanged.

An actual universe could include many subjects, resources and contextual states. Our small version lets a learner enumerate every outcome rather than rely on an ambiguous diagram. Before calculating, explain what each label contains. If two reviewers give r2 different meanings, a shared set formula cannot resolve their disagreement about the underlying request.

Contents · Next chapter

Our fictional model has grant sets G1 and G2, a limiting boundary L and a set D of applicable explicit denials. A request is permitted exactly when it belongs to at least one grant, belongs to L and does not belong to D. All four sets refer to the same universe U and fixed context.

Write the rule as E = (G1 ∪ G2) ∩ L, followed by removal of D. Equivalently, E = ((G1 ∪ G2) ∩ L) \ D. Here E is the effective permitted set, ∪ means union, ∩ means intersection and the backslash means set difference.

These symbols express an explicitly supplied contract. They do not discover the platform’s behaviour. Some systems support different combining algorithms, policy categories, principals, inheritance rules and exception paths. A real access review must establish those semantics before using a convenient equation.

The Zero Trust subject guide supplies the wider resource-focused purpose. This article isolates one part of that task: calculating how multiple policy contributions combine. Neither the name of a role nor a successful sign-in tells us which combining operation applies to each category.

Contents · Previous chapter · Next chapter

Stipulate G1 = {r1, r2, r4} and G2 = {r2, r3, r5}. The boundary is L = {r1, r2, r3, r6}, while D = {r3}. We will inspect all six requests rather than assume that the overlap or missing entries have an obvious meaning.

The table shows several different reasons for refusal. r3 has a grant and fits the boundary but is explicitly denied. r4 and r5 have grants but fall outside the boundary. r6 fits the boundary but has no grant. Those distinctions matter when explaining the decision.

The answer is not obtained by counting favourable columns. Two yes entries can coexist with refusal, and one grant can suffice when the other requirements are met. The composition rule specifies logical relationships between columns. A majority vote would be a different, undeclared policy model.

Contents · Previous chapter · Next chapter

The union G1 ∪ G2 contains r1, r2, r3, r4 and r5. r2 appears only once in the union even though two grants include it. Duplicate authority paths do not create two copies of the same permitted request in this set account.

Intersect that union with L. The result is {r1, r2, r3}. r4 and r5 are removed because they lie outside the boundary. r6 remains absent because intersection can retain an existing element but cannot create an element missing from the grant union.

Finally remove D = {r3}. The effective permitted set is E = {r1, r2}. Check each surviving request against the original rule: it has at least one grant, fits the boundary and avoids explicit denial. Check every excluded request for the requirement it fails.

This staged account makes a disagreement easier to locate. If another reviewer obtains {r1, r2, r3}, they may have omitted the explicit denial. If they include r6, they may have treated boundary membership as a grant. The intermediate sets explain the error more precisely than comparing only two final permission counts.

Contents · Previous chapter · Next chapter

In the fictional model, r3 and r6 are both refused, but their policy evidence differs. r3 belongs to D. r6 belongs to neither grant. Calling both denied may be adequate for a simple user-facing result, yet an administrative explanation should preserve the distinction relevant to diagnosis.

Add r6 to G2 while leaving all other sets unchanged. It now satisfies the grant requirement and the boundary, so it becomes permitted. Add another grant for r3 instead, and r3 remains refused because the applicable explicit denial still removes it.

This is a useful counterexample to the idea that another allow always fixes access. Whether it changes the outcome depends on which requirement was failing. Adding a grant cannot remove an explicit denial under our declared rule, and it cannot move a request inside a boundary that excludes it.

AWS’s explanation of explicit and implicit denials provides one concrete platform reference for that distinction. Read the current rules for the actual platform and request type. The examples here use a small invented policy account so that the consequences can be checked without changing any real permissions.

Contents · Previous chapter · Next chapter

The boundary contains r6, but the effective set initially does not. That one request proves that a limiting set is not automatically another source of grants. Its presence in L means the request is within this limit, not that all other requirements are satisfied.

If someone calculates G1 ∪ G2 ∪ L and then removes D, their result is {r1, r2, r4, r5, r6}. Three requests appear that the declared model refuses. r4 and r5 bypass the boundary, while r6 acquires authority from a set that was only meant to limit existing authority.

The mistake is semantic before it is arithmetic. Union was executed correctly, but it was assigned to the wrong category of policy input. Renaming a boundary as an approval list does not settle its role. The system’s actual combining rules and the owner’s intended restriction must be understood together.

A useful review writes a short purpose beside each policy source: can grant, can limit, can explicitly refuse, or another defined role. Then trace one request through the complete composition. This is clearer than assuming that every list attached to an account contributes permissions in the same way.

An empty explicit-denial set is also a defined input, not an instruction to grant everything. If D is empty in the first account, the effective set becomes {r1, r2, r3}; r4 and r5 still fail the boundary, and r6 still lacks a grant. Likewise, an empty boundary permits no requests under this particular contract. Distinguish an intentionally empty limiting set from a missing or inapplicable boundary, whose meaning must be established separately in the actual system. Treating all three states as the same value can change the decision before any set operation begins.

Contents · Previous chapter · Next chapter

Hold L and D fixed. Adding elements to a grant can only enlarge the grant union, so it cannot remove an effective permission in this declared model. That monotonic property gives us a useful verification check, but it does not say that every added element becomes effective.

Let a new grant G3 contain {r3, r4, r6}. r3 is still explicitly denied. r4 is still outside L. r6 now has a grant and fits L, so the new effective set is {r1, r2, r6}. Only one of the three new grant elements changes the result.

The effective addition can be calculated directly as G3 ∩ L with D and the old effective set removed. This identifies newly permitted complete requests. Counting the size of G3 would overstate the actual change because some entries remain blocked or were already permitted.

Do not generalise this property to a platform whose policy language includes role conflicts, priority rules or other nonmonotonic behaviour. It follows from the equation we declared. A good test suite should check the properties of the actual model, including examples that would expose an incorrect assumption about how additions interact with restrictions.

Contents · Previous chapter · Next chapter

Hold the grants and D fixed, and replace L by a subset L_new. Then E_new is a subset of E. Tightening this boundary cannot create a permission under our declared model. It can remove a permission or leave the effective result unchanged.

For example, remove r2 and r6 from L, leaving {r1, r3}. The effective set becomes {r1}. Removing r2 matters because it was effectively permitted; removing r6 has no initial effect because r6 lacked a grant. The same boundary edit can contain both consequential and currently redundant changes.

Conversely, expanding L does not itself guarantee additional authority. If L becomes all of U, the effective set is {r1, r2, r4, r5}; r3 remains explicitly denied and r6 remains ungranted. Each input category retains its distinct role even when another restriction disappears.

This is useful when comparing proposed policy versions. Report which complete requests are newly possible or no longer possible, not only how many entries changed in a boundary document. An administrative edit and its effective consequence are different quantities. The relationship becomes clear when the unchanged grants and denials are kept in the calculation.

Contents · Previous chapter · Next chapter

Intersection distributes over union: (G1 ∪ G2) ∩ L equals (G1 ∩ L) ∪ (G2 ∩ L). In the first example, the restricted grant contributions are {r1, r2} and {r2, r3}. Their union is {r1, r2, r3}, and removing D again leaves {r1, r2}.

The two routes provide an independent structural check. One combines grants first, while the other limits each grant before combining. They agree because every element is retained exactly when it appears in a grant and inside L. The logical condition, not the visual placement of a diagram, establishes the equivalence.

Set difference can likewise be applied to each restricted grant before their union when the same D applies to both. But that condition matters. If each path has different denial semantics or a different context, substituting one common D can erase meaningful distinctions.

Use identities to verify a known contract, not to invent one. A mathematically valid rearrangement of the wrong platform model remains the wrong platform model. The review should state both the policy semantics being assumed and the identity used to simplify their calculation. This keeps a clever algebraic shortcut from hiding an unsupported implementation assumption.

Contents · Previous chapter · Next chapter

Consider the expression (G1 ∩ G2) ∩ L with D removed. It permits only r2 in the first example. It is stricter than our declared model because it requires both grant sources rather than at least one. r1 loses access despite having a sufficient grant under the intended rule.

Now consider removing D from G1 alone before taking a union with G2. Because G2 grants r3, that request can return through the second path. A global explicit denial has accidentally become a restriction on only one contribution. The expression’s grouping changes the meaning.

Small counterexamples are more informative than the claim that one expression looks safer. A rule can be unnecessarily restrictive for legitimate work or too permissive for a protected resource. Identify the complete request whose outcome differs and explain which logical requirement was changed.

For a classroom activity, ask learners to build a universe with just one request that appears only in G2 and also in D. It distinguishes global denial from denial applied only to G1 immediately. The smallest useful counterexample often reveals the composition issue faster than an enormous matrix containing many irrelevant permissions.

Contents · Previous chapter · Next chapter

Suppose a separate policy permits exactly two pairs: reading room A and updating room B. Its permitted action set is {read, update}, and its resource set is {A, B}. Those two summaries are individually true, but their Cartesian product contains four pairs rather than two.

Rebuilding permissions from that product would add updating room A and reading room B. Neither pair was supplied. Projecting a relation into separate columns loses the correlation between them. Combining the columns later cannot recover which pairings were originally allowed.

This is a different issue from union versus intersection, yet it can corrupt the sets before composition begins. A reviewer may apply every set operation correctly to a universe that has already invented cross-pair permissions. The request representation belongs in the verification, not only the combining formula.

Keep the original pairs or complete request records when a summary would lose the relationship. A table with one row per allowed pairing can be clearer than two attractive lists labelled actions and resources. If a compressed representation is used, establish exactly how it expands and test the unintended cross-pairs explicitly.

Contents · Previous chapter · Next chapter

Add a time condition to the previous example. A fictional grant permits reading room A during the morning and updating room B during the afternoon. Separately listing both actions, both rooms and both periods would create eight combinations, of which only two were granted.

Context is therefore part of the complete request. Define the granted records as tuples, such as (read, A, morning) and (update, B, afternoon). The policy calculation can then combine sets of tuples without separating conditions that belong together. At each actual context, evaluate the matching records.

The labels morning and afternoon are exact categories in this paper model. An implementation would need precise boundary times, a time source and current policy semantics. We are not supplying operational access hours or assuming a particular token carries continuously updated context.

This also explains why a static effective-permissions list can have a limited scope. It may describe one fixed context rather than every future request. Record the contextual assumptions beside the result. A valid snapshot should not quietly become a promise that the same request remains permitted after its relevant conditions change.

Contents · Previous chapter · Next chapter

A real request can contain an unknown or unavailable contextual value. Our finite examples initially avoid that complication by supplying exact membership. If we introduce missing device evidence, we must add a rule rather than silently interpret unknown as yes or no.

For a new fictional condition, stipulate that permission requires an affirmative, current match. Missing evidence fails that condition, so a request depending on it is refused in this teaching model. This is a chosen contract, not a universal conclusion about how every language evaluates absent attributes.

If another system uses a separate indeterminate result, a combining algorithm must explain how that result affects the final decision. Two-valued set membership may no longer represent every intermediate state adequately. Preserve the distinction between an explicit refusal, a missing grant and an evaluation problem where it matters to diagnosis.

The practical question is concrete: which result should the declared rule produce for this request when this particular evidence is unavailable? Test that case through authorised processes. A reassuring phrase such as context-aware access does not answer it. The expected outcome, error handling and responsible owner need an inspectable relationship to the actual enforcement behaviour.

Contents · Previous chapter · Next chapter

Initially r2 belongs to both G1 and G2. If G1 is removed, G2 still supplies r2. With the original L and D, the new effective set is {r2}. r1 disappears, but r2 remains because another grant path continues to exist.

The set of effective permissions removed is E_old \ E_new, which here equals {r1}. It is not automatically G1 or even G1 ∩ L. Overlap matters. A role-removal ticket can be completed correctly while a particular request remains permitted through a separate authorised or unintended path.

That observation does not by itself prove a revocation fault. The intended outcome must say whether one role should be removed or whether the complete request should become impossible. Those are different instructions. The business purpose and all relevant grant paths determine what needs to change.

The existing short-lived tokens and immediate revocation guide owns the additional time and session question. Our calculation concerns policy composition at a declared snapshot. A correct snapshot result does not establish when every cached or continuing session adopts it.

Contents · Previous chapter · Next chapter

Suppose a fictional account belongs to group A, which includes group B, and B includes grant G2. If the declared inheritance rule follows these memberships, G2 can contribute even when it is not directly attached to the account. The effective grant inventory must include the reachable contribution.

Represent the membership structure as a directed graph and follow authorised edges from the account. Retain a visited set so a cycle does not cause endless repetition in the paper traversal. A cycle alone does not define new grant semantics; the example assumes reachability with each discovered grant included once.

Actual platforms can prohibit cycles, restrict nesting, distinguish group kinds or evaluate other relationships. The graph is a model of a supplied rule, not evidence that a particular identity provider supports that nesting. Confirm the applicable relationship before treating a diagram edge as authority.

A useful explanation keeps provenance beside each effective request: which grant paths contributed, which boundary applied and whether a denial excluded it. This lets a reviewer identify the dependency that sustains access after one membership changes. A final yes/no list answers the decision question, while the path account helps explain and maintain that decision.

Contents · Previous chapter · Next chapter

The final set {r1, r2} does not uniquely identify the policies that produced it. One account could grant only those two requests with a broad boundary and no explicit denial. Another could use the original broader grants, narrower boundary and explicit refusal. Both yield the same effective set at this snapshot.

The two accounts may respond differently to a later policy change. Expanding the original boundary can expose r4 and r5, while expanding the already broad boundary in the minimal-grant account changes nothing. Equal current outcomes do not establish equal latent authority or change behaviour.

This is an inverse-information limit. An access observation can establish that a defined request succeeded under observed conditions, but it cannot reconstruct every hidden policy contribution. To explain the composition, obtain the relevant policy sources and their evaluation context through authorised access.

For teaching, build two alternative policy accounts with the same effective set, then choose an edit that distinguishes them. The exercise develops a useful review habit: ask which additional evidence separates competing explanations. Repeating the same successful request cannot reveal a boundary or denial that never affects that request.

Contents · Previous chapter · Next chapter

Let E_old and E_new be effective sets calculated under the same request universe and comparable context. Newly permitted requests are E_new \ E_old. Newly refused requests are E_old \ E_new. Requests in their intersection retain permission across the comparison.

Equal counts do not mean equal access. If an old set is {r1, r2} and a new set is {r1, r4}, both contain two requests, yet r2 loses permission and r4 gains it. A report saying permission count unchanged would conceal the material change.

The comparison also needs a stable meaning for each request label. If room A’s identifier was reassigned or an action’s definition changed, a matching string might no longer describe the same operation. Preserve identity and scope before interpreting the set difference as a policy-only effect.

Use the resulting differences to choose positive and negative tests within an authorised environment. A changed grant entry that has no effective consequence is still worth recording, but it is different from a newly executable operation. Clear reporting connects administrative changes with the actual requests they affect and leaves the remaining enforcement verification visible.

For each newly permitted request, retain a small decision witness: at least one contributing grant, membership in every required boundary and the absence of an applicable explicit denial under the evaluated context. In our original account, r1 can cite G1 and L. r2 can cite either grant, while its overlapping provenance should remain available if the review concerns later role removal. A witness for current permission and a complete account of all authority paths have different purposes.

For a refusal, record the failing requirement rather than invent a grant witness. r6 fails the grant condition, r4 fails the boundary and r3 encounters explicit denial. If several requirements fail, a system may report one first, but correcting it need not permit the request because another failure can remain. A diagnostic sequence should re-evaluate the complete request after an authorised correction rather than assume the first message described every obstacle.

This distinction helps keep a review proportionate. A learner can explain one outcome with a small witness, then extend to a full provenance account when the question is whether a role change removes every relevant path. Neither record should be represented as a guarantee about contexts or policy sources that were outside the review. Choose the record that answers the question and make its scope visible.

Contents · Previous chapter · Next chapter

Use a new universe {a, b, c, d, e, f, g, h}. These letters denote eight complete requests with fixed meanings. Stipulate G1 = {a, b, d, f}, G2 = {b, c, g}, L = {a, c, d, g, h} and D = {g}.

First combine the grants: {a, b, c, d, f, g}. Restrict to L to obtain {a, c, d, g}. Remove D to obtain E = {a, c, d}. Check that h is not permitted despite boundary membership, and b is not permitted despite appearing in both grants.

Now remove G2. The remaining effective set is {a, d}; c loses its only surviving grant, while b remains outside L. Restore G2 and add b to L. The effective set becomes {a, b, c, d}. g remains refused because its explicit denial is unchanged.

This changed account tests more than copying the first table. It includes overlapping grants, a boundary-only entry and a denial that remains decisive after expansion. Explain each difference through the declared rule. A final answer without that explanation gives less evidence that the composition has been understood.

Contents · Previous chapter · Next chapter

Exercise one: construct one request that proves a boundary is not a grant. Put it in L but in neither grant and outside D. The declared model refuses it. The mistaken union-of-everything model permits it. One request is enough to distinguish the interpretations.

Exercise two: construct one request that remains permitted after a role is removed. Put it in both grants, inside L and outside D. Removing either grant leaves the other. Then remove both and explain the changed outcome without inventing an explicit denial.

Exercise three: construct two permitted action-resource pairs whose separate action and resource lists create unintended combinations. Reading A and updating B work. Identify reading B and updating A as the additional pairs introduced by reconstruction from the projections.

These small constructions make useful learning checks because they target different errors. If the learner confuses missing with explicitly denied, return to the policy categories. If they lose action-resource correlation, repair the request representation. Once the gap is corrected, change the examples and ask for a fresh counterexample without the original labels.

Contents · Previous chapter · Next chapter

The repair route uses ordinary sets before platform terminology. Sort complete request cards into grant, boundary and explicit-denial groups, then calculate one final result. Ask the learner to explain why a boundary-only card remains refused and why a denial survives an extra grant.

The stabilisation route compares policy changes. Add a grant, tighten a boundary and remove an overlapping role, one change at a time. Predict which changes can enlarge or shrink the effective set under the declared model. Then verify the prediction by enumerating requests.

The extension route uses tuples, inheritance graphs and inverse alternatives. Preserve action-resource-context correlations, identify all contributing paths and construct distinct policy accounts with the same current result. Keep actual-platform exceptions separate from the teaching contract rather than silently widening its claims.

The Education parent on independent learning and transfer connects the reasoning to a wider goal. Understanding appears when someone can explain a new permission outcome and identify the rule or evidence that would change it. Memorising union and intersection symbols without attaching them to the right policy categories is not enough.

Contents · Previous chapter · Next chapter

Does an extra grant always permit a refused request? No. In our model it can supply missing authority, but the boundary and explicit denials still apply. Does a boundary entry grant permission by itself? No. Its role is to limit the grant union under the declared contract.

Does removing a role always remove its permissions? It removes that role’s contribution. Another grant path can preserve a particular effective request. Calculate the complete result and compare it with the intended outcome before concluding that the removal succeeded or failed in its wider purpose.

Can a permission count establish least privilege? No. The identities of the requests, their resource scope, conditions and relationship to legitimate work matter. Two equal-sized sets can authorise very different operations, as the version comparison demonstrates.

Can this formula be copied directly into every zero-trust implementation? No. Zero trust describes a wider access approach, while platforms define concrete evaluation semantics. Establish the current rules for the actual principal, resource, policy types and context. Then verify intended successes and refusals through authorised testing. The finite model is a learning tool for asking those questions precisely.

Contents · Previous chapter · Next chapter

Return to Zero Trust: justified resource access for identity lifecycle, enforcement and operational ownership. Continue to viewing versus exporting when the issue is the scope of different operations and data paths. Use token expiry and effective revocation when timing and continuing sessions are central.

For language that preserves the actual access model, read localising role-based access and admin permissions. Its interface and translation checks complement the set account here; wording should not merge explicit denial, missing assignment and inherited access into one misleading category.

Use IT Service Management for ownership and controlled change, and Networks for communication paths. The How X Works hub supports wider reading. Choose by the unresolved question: composition, action scope, time, language, service operation or network reachability.

Contents · Previous chapter · Next chapter

NIST SP 800-207, Zero Trust Architecture, provides the primary resource-focused architecture context. AWS IAM policy evaluation logic provides a concrete example in which some policy categories combine through union and others through intersection, with applicable explicit denials taking precedence. Its linked qualifications and principal-specific rules matter for actual AWS requests.

The AWS explicit-versus-implicit denial guide supports that terminology distinction. These primary routes were checked on 23 October 2026. The article does not configure an account, certify a policy or claim that its simplified equation exhausts any provider’s evaluation rules.

All request universes, grants, boundaries, graph examples and counterexamples above are original fictional constructions. Their results follow from the contract stated in chapter two. Preserve that contract, the complete request representation and the current evidence when transferring the method. A dependable access explanation can show what was requested, which rule applied and why the resulting permission changed.

Contents · Previous chapter · Return to Zero Trust