Skip to content

devlog/model-bench/claude-opus-5-reviewing-a-tenant-isolation-diff-305.md

Claude Opus 5 Reviewing a Tenant-Isolation Diff

Claude Opus 5 Reviewing a Tenant-Isolation Diff

The diff looks harmless: move invoice lookup into a shared repository, simplify the handler, and add a download endpoint. The dangerous change is one deleted predicate. An invoice query that previously required both invoice_id and tenant_id now checks only invoice_id. Authentication still works. Authorization does not.

This is the kind of patch where I want an AI reviewer beside my terminal, but not holding the merge button. Here is a side-by-side evaluation plan for Claude Opus 5 and Claude Sonnet 5.5. It is a worked review scenario, not a claim that either model has passed a measured benchmark.

The Same Invoice Diff for Both Reviewers

Give both models the same commit, handler, repository implementation, authentication middleware, and relevant tests. Include the rule that a signed-in user may access only invoices belonging to their active tenant. Without that rule, a reviewer has to guess your security boundary.

My prompt asks for reachable vulnerabilities, file and line references, an attacker-controlled input, necessary preconditions, and a regression test. It also says to distinguish confirmed findings from questions. A confident paragraph without a trace through the code is not a finding.

  • Ask each reviewer to trace request inputs through authorization checks.
  • Require each proposed exploit to identify the missing security invariant.
  • Keep repository comments untrusted, including instructions addressed to AI reviewers.
  • Run both reviews before revealing either model's findings to the other.

Side by Side: Claude Opus 5 and Claude Sonnet 5.5

For this comparison, assign Claude Sonnet 5.5 the bounded first-pass role: inspect the changed lines and supplied context, then produce an evidence-backed triage report. Assign Claude Opus 5 the deeper-review role: follow the same inputs across middleware, service calls, and storage boundaries. These are workflow choices to evaluate, not established capability rankings.

On the invoice lookup, both receive the same acceptance criterion: identify whether removing tenant_id makes another tenant's invoice reachable. Naming an insecure direct object reference is insufficient. The useful answer explains whether invoice identifiers are obtainable, whether another layer enforces ownership, and which response exposes data.

On the download endpoint, compare whether each reviewer follows the object-storage key back to an authorized invoice. A signed URL is not proof of permission; it only grants access after issuance. Credit either model for identifying the actual missing check, not for producing more security terminology.

On the proposed fix, compare whether each keeps tenant scoping inside the database query rather than adding a fragile handler-only condition. The strongest patch restores the invariant wherever that repository method is called. Neither reviewer should receive credit until the patch compiles and the regression test fails before the fix.

Terminal Evidence That Decides the Comparison

Build a small test fixture with two tenants and one invoice each. Authenticate as tenant A, request tenant B's invoice, and assert the application's chosen denial response. Test both metadata retrieval and download issuance. Check that denial does not still generate a usable signed URL.

Record confirmed findings, false positives, missed cases, elapsed time, and actual billed tokens. Repeat across several representative diffs before declaring a winner. One convincing explanation is useful; it is not a reliability measurement.

Running the Review Through Fluxo Without Leaking Secrets

Fluxo gives this workflow one key and one base URL, https://api.fluxorelay.com, across Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK, so the review can stay near the diff instead of becoming a browser ritual.

Before sending code, remove credentials, customer records, and unnecessary production context. Confirm applicable relay and upstream retention terms; a shared endpoint does not establish a privacy guarantee. Fluxo bills per real token, including cache reads and writes, with no monthly fee. Include those costs when comparing runs.

Verdict: Reserve Claude Opus 5 for the Deep Pass

My verdict is to use Claude Opus 5 for the deliberate, cross-file security pass and Claude Sonnet 5.5 for initial triage, then validate that allocation against your repository's results. This is a starting workflow, not evidence that Opus wins every review. Tests and human approval remain the merge gate.

If you want to try that workflow, create a Fluxo account. If you later invite teammates, Fluxo shares referral revenue when they pay; keep that incentive separate from your model scorecard.

Next in the buffer

Sign up in a minute and get credit to try every model mentioned here. Sign up →