AI-Generated Code Security Checklist

Coding agents produce plausible code at volume. Some of it reproduces insecure patterns from public code, some misunderstands your internal APIs and security conventions, and all of it arrives faster than reviewers can read. The defensible posture is to treat generated code as untrusted input to a verification pipeline and to bound what the agent can reach while it works. This checklist lists the controls. It applies the agentic SDLC whitepaper and the general AI security checklist to the code pipeline.

What pipeline checks must generated code pass?

• Build succeeds and all tests pass; coverage does not fall.
• Static analysis with architectural rules encoded as checks (forbidden patterns, layering, complexity).
• Security-focused static analysis for injection, unsafe deserialization, path traversal, and similar classes.
• Dependency verification: every new dependency exists, comes from an approved registry, passes vulnerability and license checks, and is on the allowlist or reviewed.
• Secret scanning on the diff and the repository.
• Security tests for authentication, authorization, input validation, and data handling paths touched by the change.
• Spec conformance: scope respected, prohibited files untouched, acceptance criteria met.
• Behavioral evaluation for AI features; see AI regression testing.

How do you stop agents from weakening the gates?

• Changes to test files, CI configuration, static-analysis rules, and security policies require a separate, human-reviewed change.
• Coverage and test-count regressions block merges.
• Skipped or disabled tests are flagged and require justification.
• Agents cannot approve or merge their own pull requests.

What access boundaries apply to agents?

• Agents run under scoped identities with write access only to designated repositories and branches.
• No production credentials, secrets, or customer data in agent environments.
• Isolated development environments with controlled egress.
• Repository-level protections for security-critical paths that require human authorship or pairing.
• Data-handling policy: which code may be sent to which model providers, with residency and retention terms. Reference: the agent identity and access control whitepaper.

Which review rules apply by risk class?

Risk class	Examples	Requirement
Low	Docs, tests for existing behavior, isolated refactors	Gates; sampled human review
Medium	Feature code behind flags, internal APIs	Intent and architecture review
High	Auth, payments, migrations, public APIs, infrastructure	Line-level review by named owners; two approvals
Critical	Security controls, cryptography, compliance logic	Human-written or paired; agents assist only

• Risk class is recorded on every specification and pull request.
• Reviewers for high and critical classes are named owners with security training.

What must the audit trail contain?

• Whether the change was agent-generated, and by which tool and model version.
• The specification it implements.
• Gate results and any waivers with approvers.
• Reviewers and approvals by class.
• Links from incidents back to the generating specification and change.

What about prompt injection in the development environment?

• Agents that read repository content, issues, or documentation treat that content as untrusted; instructions embedded in comments or issues cannot trigger consequential actions.
• Agents that browse or fetch external content during implementation run with the same boundaries.
• Injection tests are part of the tooling evaluation. Reference: what is indirect prompt injection.

How should the checklist be operated?

• Owned by the platform or security engineering team; reviewed quarterly as tools change.
• Metrics tracked: gate failure causes, dependency rejections, secret-scan hits, security findings traced to generated code, and change failure rate.
• Incidents involving generated code feed rule updates and, where relevant, the specification template.
• Tooling changes, a new agent, model version, or plugin, trigger a re-run of the injection and dependency tests before the tool is approved for use.

What does "done" look like?

Every generated change passes stricter gates than a human change would have, cannot have weakened those gates, was produced under an identity that could not reach production, was reviewed according to its risk class, and can be traced from incident to specification. Adoption sequencing is in how to adopt AI coding agents safely.

How does FISTA Solutions help?

FISTA Solutions installs these controls in client pipelines as part of its AI enablement practice and applies them to its own delivery, with forward deployed engineers configuring gates, access boundaries, and review policy inside your teams. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To run this checklist against your pipeline, message FISTA on WhatsApp, or read AI code review for how agents can also strengthen review.