AI-generated code does not fail security in exotic ways. It fails in the ordinary ones, made at speed: a list query that forgot the current customer, an admin action the UI hides but the server never checks, a record anyone can fetch by changing the ID, a key in a config file, user text rendered as HTML. The evidence says this happens a lot, and that the people accepting the code feel more confident than they should. This page is the checklist, the research, and how Firetrail runs it on every PR and across the whole codebase.
updated September 4, 2026 · every fact links to where we checked it
The same five failures, whether the code came from Claude Code, Cursor, Codex, Copilot or a person in a hurry.
Every list, search, report and export must return only rows that belong to the person asking. The failure: a query that filters by status but not by organization. First work out how your app fences data (row-level security, a tenant middleware, manual scoping), then look for where the fence is missing.
The interface hides the delete button for non-admins; the endpoint behind it doesn't check who is calling. Cross every role gate in the frontend with the handler it talks to. Generated code is especially prone to this because the UI and the API were written separately.
IDOR: a route that loads an object by ID without checking it belongs to the caller. Invoice.find(params[:id]) instead of current_organization.invoices.find(...). Walk every route handler, not a sample.
Keys, passwords and signing secrets in source, config, Docker, CI, charts, scripts or docs; defaults that become the real secret when nobody overrides them; secrets still in git history; keys shipped in the frontend bundle.
XSS: innerHTML and its equivalents, unsanitized markdown, user-controlled links, eval, and the same failure in server-side emails and templates. This is the check AI models fail most often.
Not one of the five, but the sixth thing worth a look on generated code: personal data written to logs, analytics without consent, retention nobody decided. Priya's lane.
Veracode, 2025. The GenAI Code Security Report had more than 100 large language models complete coding tasks in Java, JavaScript, Python and C#, then scanned the output. 45% of the samples introduced a security flaw from the OWASP Top 10. Cross-site scripting (CWE-80) went undefended in 86% of cases and log injection (CWE-117) in 88%. Larger and newer models produced code that compiled and worked more often, and were not meaningfully safer.
Stanford, Perry et al., ACM CCS 2023. 47 participants did five security-relevant tasks in Python, JavaScript and C, half with an AI assistant. The assisted group wrote significantly less secure code and was more likely to believe it had written secure code. The participants who trusted the assistant least and edited prompts most produced the fewest vulnerabilities.
The mechanism is not mysterious. A model reproduces the most common way to write something, and the most common way in public code is often the unsafe one: the query without the tenant filter, the innerHTML assignment, the default secret in the example config. It also can't see the fence your application uses unless someone tells it, and the tests it writes test the feature, not the authorization around it. None of this is specific to one tool.
What follows for review. Treat generated code as unreviewed for security even when it's reviewed for correctness. Check the five failures on every change that touches a query, a route, a template or a config file. And once in a while, check the whole application, because the ones already merged are still there.
A per-PR review catches the failures in the lines that changed. The audit finds the ones already merged. Every plan.
Create a personal token on the MCP page in the app and add the Firetrail server to Claude Code, Cursor, Codex, VS Code or any MCP client with the snippet the page shows. Once per person, about two minutes.
security audit this repository with Firetrail, or for one PR's files and the code paths they reach, security audit PR 412 with Firetrail. In Claude Code the slash command /mcp__firetrail__security_audit is the same thing.
It works out how your app fences data, then walks every route handler and every deploy file. It reports only what it verified: file, line, the snippet, why it's exploitable, the impact, and the fix. Secrets are masked. When a check doesn't apply to your stack, it says so instead of inventing findings.
Fix these first (critical and high, open at the top); what is already protected, with the evidence; the five checks each explained in the same words on every audit, with your findings collapsed under them; P1/P2/P3 recommendations; ready-to-file GitHub issues in Markdown with a copy button; and how the audit was run. Prints cleanly to PDF.
The security and privacy findings from the review team on recent PRs, and the files with a history of causing bugfixes, go in as leads for the agent. Firetrail runs no AI of its own for the audit and never reads your working tree.
where Firetrail does this for you
The page is private to your organization by default and can be flipped to a public link. Republishing an audit later keeps the same link, so the one the team bookmarked stays current.
Two of Firetrail's reviewers read a PR through a security lens. Rick, Senior Security Engineer, covers secrets, authentication and authorization, tenant isolation, unsafe input and output, and how the change could be abused. Priya, Privacy & Compliance Engineer, covers what happens to people's data: personal information you didn't need to collect, consent, GDPR/CCPA obligations, retention, third parties, and sensitive values ending up in logs. Each lands on a yes/meh/no verdict with findings that name the files.
Two of the structural checks matter here too, on every plan: Global Config Change flags configuration with production blast radius (auth settings, CORS, environment, CI) and Package Update flags a real dependency change, both of which are where a generated PR most often changes something security-relevant without saying so. Intent drift (Pro and up) catches the undisclosed change itself.
Each project picks the reviewers for its pull requests, and any reviewer can take a slot: Free has one slot, Starter three and Pro six, and Business runs all ten on every PR. A backend-heavy team often gives a slot to Rick for the security lens it lacks, and a team that handles personal data keeps Priya in its lineup.
Firetrail is not a replacement for a scanner. Here is how the pieces fit.
| Approach | What it finds | Scope | Setup | Cost |
|---|---|---|---|---|
| SAST and dependency scanners (Semgrep, CodeQL, Snyk, Dependabot) | Known vulnerable patterns and packages, by rule; no judgment about your tenancy model | Whole repository, every commit | CI integration, rule tuning per language | Free tiers to enterprise; keep one regardless of anything else on this table |
| Review bots with security categories (CodeRabbit, Claude Code Review) | Line-level issues in the diff, some tagged security; CodeRabbit runs SAST tools inside the review | The changed lines, plus repository context | Install the app | Per seat or per review; see the comparison |
| Firetrail per-PR review | Rick's and Priya's verdicts and findings on the change; config and dependency blast radius; undisclosed changes | The PR's diff | Install the GitHub App | Free with Rick as the chosen reviewer; Starter $24, Pro $39 and Business $49 per active developer per month |
| Firetrail Security Audit | The five failures, verified with evidence, ranked by what to fix first, explained for the whole team, with issues ready to file | The whole application, or one PR's files and the paths they reach | Connect your coding agent once | Every plan; the agent's reading runs on your own account, Firetrail renders the page at no extra cost |
The best available evidence says it often is, and that people trust it more than they should. Veracode found OWASP-class flaws in 45% of AI-generated samples across 100+ models, and the Stanford study found assisted participants wrote less secure code while feeling more confident. Treat generated code as unreviewed for security until someone checks the five failures.
Yes, with limits. A different reviewer with a specific checklist and a requirement to show evidence catches the ordinary failures well; that is how Firetrail's Rick and the Security Audit are built. Neither is a substitute for a scanner in CI or for a human who understands your tenancy model.
No. Scanners find known patterns and vulnerable packages by rule, everywhere, on every commit. Firetrail's reviewers and audit apply judgment about your application: is this query fenced, is this permission checked server-side, does this ID belong to the caller. Run both.
Your own coding agent does the reading in your checkout, on your account, and sends Firetrail only the findings, as data. Firetrail renders and hosts the page, adds the ranking, the explanations and the issues, and contributes what it already knows from analyzing your PRs. It never reads your working tree.
Yes. The secrets check covers source, config, Docker, CI, charts, scripts and docs, defaults that become the real secret, secrets still in git history, and keys shipped in the frontend bundle. Found secrets are masked to their last four characters on the page.
The Security Audit is on every plan, including Free. Rick and Priya can review a project's PRs on every plan when they are in its lineup: Free has one slot, Starter three and Pro six, and Business runs all ten reviewers on every PR.
Connect your coding agent, say “security audit this repository with Firetrail”, and read the fix-first page. Every plan, including Free.