Working a scan report of access-control leads

A report is a list of leads

A finding is a lead, not a confirmation. Aevral runs no validation pass on findings and does not generate patches. The GitHub Check is the scan outcome on that commit, with a link to the report. The console report is every finding with its evidence: the file, the lines, and the reason a human should look. A scan is not a clean bill of health, and a longer list is not a more certain one.

The expensive failure modes are both ends of the same mistake. Treat every lead as a ticket and the queue never ends. Ignore the report because it is a list and the access rule that moved stays moved. The useful middle is a short procedure: open the leads that rewrite a rule, settle each one with evidence, hand one at a time.

Open the leads that rewrite a rule

Aevral does not rank the report for you. The order below is a human procedure, the same surface the pull-request checklist uses, applied to a snapshot instead of a diff.

Start with gates that disappeared. A route or handler with no visible role check or middleware in front of it is the function-level shape: under-guarded routes, the OWASP API5:2023 entry, Broken Function Level Authorization, within the broader CWE-284 category, Improper Access Control. If you cannot point at the gate, treat the lead as a missing gate until the evidence says otherwise.

Then the lookups the caller names. An id in the path or body reaching a query with no owner scoping attached is the object-level shape, the OWASP API1:2023 entry, Broken Object Level Authorization, whose related weaknesses include CWE-639, Authorization Bypass Through User-Controlled Key. The tell is a fetch by id with the tenant binding in a different clause, or not in the query at all.

Then the business-logic rules that moved. A prefix match that used to be equality, a role list grown by one, a check that used to sit in one place and now sits in a caller that not every path uses. None of those lines looks wrong in isolation. Each redefines who has access to what.

Three questions that close a lead

A lead is ready to act on when you can write three things: the rule in question (who may access this object, and where that is enforced), the evidence (file and lines), and the actor (which role or session the route assumes). That is the same bar a finding has to meet to be worth a human's time, and the same bar the pull-request checklist uses before approval.

If one of the three cannot be written down, keep reading the code around the finding. If the lead does not hold, leave it. Aevral does not auto-resolve findings. A later scan is a new snapshot of the default branch, not a verdict on the last one.

Hand off one lead at a time

When the three questions have answers, copy the fix prompt for that one finding into Claude Code, Cursor, or Codex. The prompt already carries the evidence, the rule, the boundary, and the review gate. Do not paste the rest of the report into the same thread. A coding agent given a list of leads will wander; a coding agent given one closed lead will stay on the gate.

Nothing in this flow auto-merges, commits, or opens a pull request; a human reviews before merge. The finding stays a lead until that review. The agent patch stays a proposal until that same human reads it. The walkthrough for the prompt itself is a separate page; this page stops at the decision to hand one lead over.