Inputs and trust boundaries
Map browser input, API payloads, webhook events, file uploads, model output, and internal tool calls before judging individual functions.
AI code security
AI Code Security: A Practical Threat Model for AI-Generated Software
AI code security is the practice of reviewing AI-generated software across its actual trust boundaries and runtime systems. Combine deterministic scanners with contextual review and direct evidence from the database, repository, dependencies, and deployment; do not rely on a language model's opinion alone.
Reviewed by Sentrail · Updated August 17, 2026
Threat model
Start with boundaries, not with who wrote the code.
Generated and hand-written code can expose the same classes of risk. The review should follow data, identity, privilege, and deployment paths.
Identity and authority
Trace how a request becomes a user, tenant, role, or privileged service action. Review authorization at each data-changing boundary.
Data and secrets
Identify sensitive records, credentials, tokens, logs, and generated output. Verify where they can flow at runtime and in the build pipeline.
Dependencies and deployment
Include package advisories, CI permissions, environment-variable exposure, preview environments, and hosting protection in the model.
Analysis layers
Use different tools for different kinds of evidence.
Static analysis
Semgrep
Find code patterns that match known unsafe constructs. Treat results as findings to triage, not automatic proof of exploitability.
Secret scanning
Gitleaks
Search the commit contents for credential patterns, then fingerprint and redact matches before contextual triage.
Dependency analysis
OSV-Scanner
Resolve package manifests against the OSV vulnerability database and review whether affected versions are actually present.
High-risk file review
Contextual
Read auth, middleware, webhooks, environment plumbing, and migration files because important authorization mistakes are rarely one-line patterns.
Runtime controls
Review what the code can reach and what each identity can do.
Authorization
Verify ownership and tenant checks on reads and writes. A route protected by login still needs object-level authorization.
Database controls
Inspect RLS status, policy counts, policy expressions, grants, security-definer functions, and exposed schemas using the live database configuration.
Deployment posture
Classify environment variables by exposure risk and inspect hosting protection. Local configuration does not establish production posture.
Evidence freshness
Bind findings to a commit and timestamp. When required evidence fails, has never run, or is stale, return insufficient evidence instead of a score.
Repeatable workflow
From commit to a finding a reviewer can act on.
- Scan01
Collect deterministic signals
Run secret, dependency, and static-analysis scanners against an isolated copy of the commit.
- Triage02
Add repository context
Redact secret values, inspect nearby code, and distinguish a likely true positive from noise or an uncertain result.
- Report03
Keep the decision visible
Post findings to the pull request and check run, with merge blocking on critical results only when the repository opts in.
Webhook
A push or pull request on a monitored repository queues a scan run.
Scanners
An isolated scanner service runs Gitleaks, OSV-Scanner and Semgrep against the commit tarball.
Redaction
Matched secrets are fingerprinted and redacted before any finding reaches a language model.
Triage
Findings are ranked and labelled — true positive, likely false positive, needs review — with reasoning attached.
Report
Results post back as a pull request comment and a check run. Blocking merges on criticals is opt-in per repository.
LLM review limitations
A fluent explanation is not security evidence.
A language model can explain code and connect context across files, but it can miss paths, hallucinate configuration, misunderstand runtime state, and produce different answers for the same input. It also cannot infer the current database or deployment configuration from repository text alone.
The stronger pattern combines deterministic rules, direct system evidence, and contextual analysis. Each compensates for a different blind spot, while a human retains the final remediation decision.
Human approval
Automation can propose a fix without owning the merge.
Proposal
The agent writes a fix proposal — SQL, or exact file contents — against the finding. Nothing is written to your database or repository at this stage.
Awaiting approval
The proposal parks in an approval queue with its diff, its blast radius, and the finding it closes. Sensitive actions cannot skip this queue.
Human approval
A reviewer on your side approves or rejects. Approval is recorded with who approved it and when.
Draft PR only
On approval Sentrail opens a draft pull request on its own branch. It re-checks the base commit first and aborts if the branch moved underneath it.
You merge
Sentrail never merges. Every change lands through your normal review and CI, and the re-verification scan runs after the merge you performed.
Engineering checklist
A minimum AI-code security review.
- Map inputs, identities, data, and privileged actions
- Scan the exact commit for secrets
- Run static rules and triage their context
- Resolve dependency versions against advisories
- Read auth, middleware, webhook, and migration files
- Inspect database controls from the live configuration
- Verify environment-variable and deployment protection
- Record missing, failed, and stale evidence explicitly
- Require human approval for security-sensitive changes
- Re-run checks after the approved change lands
Review the code and the systems it depends on.
Run current checks across your repository, database, dependencies, and deployment, then keep every proposed change behind human approval.