AI Security Code Review: A Synthetic Authorization Example

Start with an example you can evaluate

An AI security review is useful when its claims can be traced to the supplied code and its proposed correction can be tested. This walkthrough uses a small, synthetic invoice lookup with a known authorization defect. It contains no customer data and contacts no external service.

The prompt and expected findings below are reference review material, not a captured model response or a benchmark of CyberRouter’s accuracy. Run the example with your chosen model and compare its answer against the rubric.

The code and the trust boundary

INVOICES = {"inv-1": {"id": "inv-1", "owner_id": "alice", "amount": 50}}


def get_invoice(user_id, invoice_id):
    """Flawed example: accepts an authenticated user but never checks ownership."""
    return INVOICES[invoice_id]

For this exercise, the authentication layer establishes the caller’s user ID, and only an invoice’s owner may read it. The lookup accepts user_id but never uses it. The missing control is object-level authorization; the example does not establish how any real application authenticates users.

Download the fixture and tests. Run python3 security-review.py locally to demonstrate the original behavior and verify the corrected function. These tests exercise the fixture, not a live service.

A prompt that asks for evidence

Review the synthetic Python invoice functions below for authorization defects.
Assume the caller passes a user ID established by the server's authentication layer.
Only the invoice owner should be able to read an invoice.
Do not assume any route or middleware beyond what is shown.
Return: observed evidence, missing control, impact under these assumptions,
a minimal correction, and tests for the owner, another user, and an unknown ID.
Separate facts visible in the code from questions that need more evidence.

Append the flawed function and fixture data to this prompt. Keep the corrected implementation and expected findings out of the model input when evaluating the review. Use the quickstart with an eligible :cyberrouter model, or follow the OpenCode setup guide. Send only the synthetic sample for this exercise.

Evaluate the answer against a rubric

An answer that invents a SQL-injection flaw, assumes a public production endpoint, or claims to have exploited a real service fails the evidence check. A correct explanation also needs a correction that passes the intended access tests.

The OWASP authorization guidance provides further context for enforcing permissions and testing access controls. A model’s reference citation still needs to be checked against its actual recommendation.

Inspect what CyberRouter added

After your run, inspect the delivered-reference trace under cyberrouter.enhancement and the usage receipt. Record the served model and endpoint, model settings, references actually delivered, input/output usage, and gateway fee. An enabled enhancement does not prove every reference was useful or that the answer was correct.

To compare approaches, hold the task, model, endpoint, and settings constant. A direct-provider baseline and a manually supplied checklist can help isolate the value of automatically selected references. Repeat tasks and record failures as well as successes before claiming an improvement; this walkthrough establishes no measured quality uplift.

Extend the fixture to your own policy

The corrected sample assumes one owner per invoice. Team membership, administrator access, delegation, and revocation require their own policy and tests. In a database-backed application, scope the query to permitted records rather than fetching broad data and relying on presentation logic.

Keep examples bounded enough to review manually, then add realistic cases one at a time. Use the context budget calculator to reserve room for code, relevant policy, references, and the review output. Estimate the separate charges with the BYOK cost guide.