How do you review an access-control code change safely?

Authentication establishes who or what is making a request. Authorization decides whether that subject may take this action on this resource in the current context. A valid session answers the first question, not the second. Public operations may intentionally allow unauthenticated access, but that outcome should still follow an explicit access rule. Start the review by writing the expected allow or deny decision in plain language before the implementation's role names shape your assumptions.

Use five fields: subject, action, resource, context, and trusted enforcement point. Add ownership, tenant, relationship, workflow state, or time constraints when they affect the result. If the required rule cannot be stated clearly, record that ambiguity as a review finding rather than treating the current condition as the contract.

List the entry paths that can reach the effect: HTTP handlers, GraphQL resolvers, background jobs, internal services, import tools, scheduled work, and administrative adapters where they exist. Follow each path until you find the component that has both the trusted subject context and the resource data needed to make the decision. A check in one controller does not protect another caller automatically.

Consider a fictional archiveProject operation called by both an HTTP endpoint and a queued maintenance command. A proposed patch adds isManager to the HTTP handler only. The review is not complete until it explains the second path, distinguishes any intermediary service identity from the originating subject, and shows where the system proves that this manager belongs to this project and tenant before archival begins.

Function-level access asks whether the subject may invoke the operation at all. Object-level access asks whether it may act on this particular record. Field-level access separates attributes that may be read from those that may be changed. Tenant-level access prevents an otherwise valid role from crossing an isolation boundary. A broad role check can pass while any one of these narrower decisions is still wrong.

Context can narrow the rule further: a project state, approval stage, relationship, delegated scope, or time window may change the outcome. Review the rule the application actually promises instead of forcing every system into one RBAC, ABAC, or relationship-based model.

Begin with one clearly allowed subject-resource pair, then change one meaningful fact at a time. Try a lower-privilege subject, a same-role subject acting on another owner's resource, and a same-role subject from another tenant. Add missing, expired, or stale context when the rule depends on it. These nearby cases are more informative than a random collection of invalid requests because each one falsifies a specific part of the decision.

For the archiveProject example, the strongest small test set includes the intended project manager, a manager for a different project, and a manager from a different tenant. Exercise materially different entry paths as well. Keep the fixtures synthetic and verify the decision before any archive state, message, or external request changes.

Authorization must happen before the protected side effect. Trace writes, emitted messages, external calls, and cache changes around the denial path. A response that says denied is not enough if the operation already changed durable state or started work that cannot be recalled.

Also review how permission changes reach long-lived tokens, queues, workers, and caches. The right propagation rule depends on the system, but the change should make its expiry, invalidation, re-check, or reconciliation behavior explicit. Keep audit evidence useful without logging credentials, bearer tokens, private payloads, or unnecessary identifiers.

A focused pull-request review can expose missing decisions, misplaced enforcement, and weak denied-path evidence. It cannot enumerate every reachable path in an unknown architecture, prove that a framework is configured correctly, or establish that no bypass exists. Passing the listed cases supports those cases only.

Escalate when the change introduces a new trust boundary, delegation model, cross-tenant workflow, high-impact administrative action, or uncertain identity propagation. Threat modelling, framework-specific guidance, dynamic security testing, and specialist review answer broader questions than this code-reading workflow can settle.