How to review authorization changes in an AI-written PR

When an AI-written PR changes an authorization check, start with the rule it is meant to preserve: which identity may do which operation on which resource. Then trace every changed route to the decision point, including the path that must be denied. A plausible explanation and a green check are useful navigation, but the approval decision depends on the code and evidence.

Consider a PR that moves a project membership check from a route handler into shared middleware. The happy path may still work while one route passes the wrong project ID, another bypasses the middleware, or a cached role survives removal. Review the boundary, not just the function that was edited.

Write down the access rule first

Before reading the diff, state the invariant in one sentence. For example: a user can read a project only while their current membership grants access to that project. Name the caller, resource, operation, and revocation behavior. If the ticket or policy does not say when membership changes take effect, ask the owner. Do not let the agent choose that security tradeoff by default.

In Review Assist, the committed Intent Document at .intent/<branch>.json records the original ask in problem.user_asks, constraints in approach.requirements, and explicit assumptions. Compare those with the ticket or policy. An agent can faithfully describe an implementation of the wrong rule.

Trace the decision through each affected path

Start at an endpoint affected by the diff and follow the identity and resource ID to the check. Check where the identity came from, whether the resource ID comes from the request or a trusted lookup, whether the check happens before data is read or mutated, and whether every affected route uses it. Look at errors and fallback branches, not only successful requests.

For the middleware move, ask whether a user can swap the project ID in the URL, body, or query string and reach a resource they do not belong to. Check list endpoints, background jobs, and alternate handlers that may not pass through the new middleware. If the change broadens access for service accounts or admins, find the explicit requirement for that exception.

The guided tour anchors each Intent Document stop to diff hunks. Use it to find the changed handlers and policy code, then follow the call path beyond the highlighted lines. Tour coverage tells you the change was explained; it cannot prove that all access paths are safe.

Challenge the assumptions that decide the boundary

Authorization bugs often hide in a premise: roles are immutable during a request, cache entries expire quickly enough, an admin exemption applies everywhere, or a resource always belongs to one project. Read each assumption's impact and verification method. For a risky premise, ask who owns the policy and what happens when it is false.

A useful review question is specific: “If membership is removed after the role cache is filled, can the same user still read the project? What invalidates that entry, and what is the maximum delay?” Record the answer against the code path. If the policy permits a delay, make that acceptance visible in the review.

Ask for denial-path evidence

A test that proves a member can read a project does not test the boundary. Ask for a nonmember request to the same resource, a member request after removal, and a request that changes the resource ID while keeping the same identity. For each, inspect the assertion: the protected data must not be returned or changed. Add an admin or service-account case when the PR changes that exception.

The document separates verification.performed from verification.not_verified. Read what ran, its result, and any attached evidence. If the denial path is absent, ask for the smallest test or manual reproduction that would settle it. The existing guide to reviewing an untested path goes deeper on that decision.

Make the approval condition explicit

Request changes when the access rule is unclear, an affected path skips enforcement, or a serious denial case is unverified. If a team accepts a bounded risk, name the policy owner, the exact gap, and the follow-up in the review. Do not convert an unverified path into a passed check to make the document look complete.

Review Assist helps place the ask, assumptions, tour, and verification beside the diff. Its local validator checks document structure, coverage, staleness, cross-references, and likely secret patterns; the GitHub App recounts coverage on the PR. Neither is a security scanner. The architecture explains the boundary between those checks and the human review.

For this PR, the closing question is simple: can you point to the rule, every path that enforces it, and evidence that the forbidden caller is denied? If any of the three is missing, the review has a concrete next request.