Security audit

A good review isn't "read every line." It answers a few questions well, in order.

1. Map the surface

List every way in: HTTP routes and API endpoints, server actions and form handlers, background jobs, webhooks, the git host, anything that runs user-supplied commands. You can't reason about what you haven't enumerated.

2. For each entry point, check two things

• Does it authenticate? Who is the caller, and is an unauthenticated request rejected where it should be?
• Does it authorise the specific object? The caller may be signed in, but are they allowed to touch this record? Confirm the id in the request is scoped to the caller's account/project — not just "any logged-in user." Missing this is the most common real bug (IDOR).

Make a table: endpoint → who may call it → what it actually checks. Mismatches jump out.

3. Follow the data to where code runs with privilege

Trace user-supplied input to anything that executes: a shell command, a database query, a template, a git operation, an AI prompt. The sharp question is whose code runs with which secrets. If untrusted code (or a check command a low-trust user can add) runs with production secrets, that's a leak path, even if no single line looks wrong.

4. Treat shared/derived content as instructions

Anything authored by one tenant that another tenant's agent will read — shared knowledge, a shared skill, a summary shown to an agent — can carry injected instructions ("ignore your rules / exfiltrate secrets / run this"). Scan it before it crosses the boundary; render it as text, never as live HTML.

5. Confirm the human gate

For anything that changes production or money, verify a person decides, the decision is logged, and high-risk actions need the review they claim to.

What to write down

For each finding: severity, who can exploit it (anonymous / any user / a low role / an insider), the file:line for every step of the path, a concrete attack, and whether you confirmed it by reading the whole path or only suspect it. "Confirmed" means you read every step — not that you ran the exploit.

Trap to avoid

Don't conclude a control is missing from one function. Trace the whole path to where the dangerous thing happens — the check often lives at the point of execution, not at the input.