AI Code Security: A Practical Pre-Production Checklist

Engineering & security guide

How Dual7's seven governed agents carry security decisions from structured requirements to human-approved production delivery.

By Dual7 · Published September 9, 2026 · Updated September 13, 2026 · 14 min read

From prompt to protected production

Short answer: AI-generated code should reach production only after it passes the same security bar as human-written code, with extra controls for context gaps, rapid change, and misplaced confidence. Dual7 carries those decisions through seven documented agents—from Requirements to Publish—with an artifact and approval point at each stage. The generator is not the security boundary. The governed lifecycle is.

• What AI code security means
• Common security risks
• Security across Dual7's seven agents
• When your existing toolchain is enough
• When a governed workflow fits
• Questions to ask a platform vendor
• Frequently asked questions

What is AI code security?

AI code security is the practice of preventing, finding, and resolving software vulnerabilities when AI contributes to the codebase. The term is used in two related ways: securing code created by AI, and using AI-powered tools to detect security problems in any code. This guide focuses on the first problem—AI-generated code security before production—while treating AI-assisted scanning as one control within a broader development process.

AI can compress the time from idea to working software. It can also produce code that looks plausible while missing part of the requirement, using an unsafe default, or applying a sound pattern in the wrong context. GitHub's own responsible-use guidance tells users to review, test, and validate generated suggestions, especially for critical or sensitive applications.

That does not mean AI-written code is uniquely unshippable. It means working code and production-ready code are different deliverables. A production decision depends on the system around the code:

• Who approved the requirement and the architecture?
• What data and identities can the feature reach?
• Which dependencies, secrets, and generated artifacts enter the build?
• Which automated and manual checks ran against the final change?
• Can a reviewer trace the deployed behavior back to an approved requirement?
• Can the team patch, roll back, and operate the software after release?

NIST's Secure Software Development Framework makes the same broader point: secure practices must be integrated into the software development lifecycle. AI changes the speed and source of code; it does not remove that obligation.

For the broader production-readiness question, see Is AI-Generated Code Production-Ready? The walkthrough below focuses on how security decisions can be carried through Dual7's documented seven-agent lifecycle.

Common AI-generated code security risks

The important AI coding security risks are familiar application-security failures appearing at greater speed or without enough system context. Reviewers should look for these failure modes rather than assume every generated change has the same risk.

AI-generated code vulnerabilities are not limited to syntax or known insecure functions. A feature can compile, pass a basic test, and still expose another customer's data or bypass a business rule. That is why a scanner-only approach is incomplete: security decisions need to survive from the first requirement to the deployed artifact.

How Dual7's seven agents carry security from prompt to production

Dual7's Governed Mode uses seven agents: Requirements, Plan, UX, Schema, Stories, Build, and Publish. Each produces an artifact for review, and downstream work remains locked until the upstream artifact is approved. The agents are Dual7's published product workflow—not a new security standard.

1. Requirements: define what must be protected

Secure delivery does not begin with a scanner. It begins with an approved description of what the feature is allowed to do.

Dual7 describes its Requirements agent as turning intent into a structured specification. That specification should identify the data the feature reads and writes, the users and services that can invoke it, the sensitive actions it performs, and the harm an attacker or mistaken user could cause.

Add security outcomes beside the functional outcomes. “A manager can approve an expense” is incomplete. The requirement should define who counts as a manager, which expenses they can approve, what happens after a role changes, and what evidence the approval creates. A generator cannot reliably implement a retention policy, tenant boundary, or permission rule it was never given.

An AI coding assistant security policy belongs here too. Define which tools are approved, which repositories and data classes they may access, what developers may place in prompts, how generated output is identified for review, and where vendor retention or model-training settings matter. Policy does not make generated code safe, but it prevents the coding tool from becoming an unmanaged data path.

2. Plan: make trust boundaries explicit

Dual7's Plan agent defines the architecture and delivery sequence. This is the point to decide where identities, data, and credentials cross a boundary—before working code makes an unsafe choice expensive to unwind.

Review the authentication authority, session model, authorization decision point, external integrations, production identities, and secret-management approach. Identify operations that require idempotency, a second approval, or an audit record. Record assumptions that later reviewers and tests can challenge.

Code review cannot rescue an architecture whose security boundaries were never defined. The plan should make those boundaries visible enough that the Schema, Stories, and Build stages can verify them.

3. UX: design safe behavior, not just screens

Dual7's UX agent produces flows and wireframes. Security decisions appear here too: who can discover a sensitive action, what must be confirmed, which fields should be masked, how sessions expire, and what an error reveals.

Hiding a button is not authorization. The UX artifact should show role-dependent states while making clear that the server and data layer remain the enforcement points. Review password-reset and invitation flows, destructive actions, exports, impersonation, approval steps, and recovery paths. Error messages should help legitimate users without exposing whether a protected record or account exists.

4. Schema: enforce isolation and access in the data model

Dual7 describes the Schema agent as producing a tenant-isolated data model. Its published security architecture says governed applications use schema-per-tenant PostgreSQL, row-level security, and role-based access control as complementary controls.

Buyers should verify how those controls apply to their own application: how a request obtains tenant context, where policies are enforced, which administrative paths can cross boundaries, and how migrations preserve isolation. Include audit records for sensitive changes and decide which fields require retention, deletion, encryption, or restricted access.

For the enterprise-review questions behind these controls, see Dual7's guide to multi-tenancy, RBAC, and audit trails.

5. Stories: turn security expectations into testable cases

Dual7's Stories agent creates user stories with acceptance criteria. This is where a security statement becomes something the Build stage can prove or reject.

Do not stop at the happy path. Require cases for no identity, the wrong role, a valid but unrelated tenant, malformed input, expired credentials, repeated requests, disabled users, stale sessions, missing dependencies, and unavailable downstream services. Cover background jobs, exports, search, and reporting—not only the visible interface.

Generated tests need review too. A model can write a test that repeats its own implementation assumptions. Acceptance criteria should express the intended boundary independently of the code.

6. Build: inspect and verify the actual change

Dual7 describes the Build agent as producing generated, validated, security-audited code. Its security page says every certified change is audited for authorization, validation, and exposure before it can ship.

That product claim is a starting point for evaluation, not a reason to skip your own review. An AI security code review should combine repository context, automated evidence, and an accountable human decision. Ask which checks run, what their coverage is, what blocks the build, and how exceptions are approved. A proportionate verification baseline may include:

• human review of the final diff in repository context;
• unit and integration tests for intended behavior and failure paths;
• static application security testing;
• software composition analysis for vulnerable dependencies;
• secret scanning for credentials, tokens, and private keys;
• infrastructure and configuration checks;
• dynamic or API testing for exposed applications.

Inventory new packages, generated files, migrations, infrastructure changes, and external APIs. Check provenance, version constraints, maintenance status, and license compatibility. Keep changes small enough to review; a large one-shot feature can conceal a dangerous line inside thousands of plausible ones.

The goal is not a wall of green badges. Each important risk should connect to a review, test, or control that can fail the build.

An AI code security scanner can help surface insecure patterns quickly in an IDE or CI/CD pipeline. It cannot prove that the requirement was correct, the tenant boundary is complete, or the business rule matches the organization's intent. Treat scanner output as evidence within the Build agent—not as a substitute for the other six agents.

7. Publish: bind human approval to the artifact that ships

Dual7 says the Publish agent ships through the customer's Git to the customer's cloud. Its public workflow also says a human signs off before anything reaches production.

The approval should bind the requirement, plan, schema, acceptance criteria, reviewed change, test results, security findings, and deployable artifact. A reviewer should be able to answer what changed, which requirement authorized it, which checks ran on that revision, which findings were fixed or accepted, and who approved the release.

The operating path matters after approval. Confirm the runtime identity, network exposure, managed secrets, logging, backup, rollback, vulnerability intake, and patch owner. Code ownership should survive a vendor change: Dual7 says governed projects produce exportable React/Next.js, Node.js, and PostgreSQL code that can move through the customer's Git and run on the customer's infrastructure. See what code ownership means in an AI builder before accepting “export” as a sufficient answer.

Together, these seven agents make security review part of the path from requirement to release. They do not replace your threat model, independent testing where warranted, operational monitoring, incident response, or accountable risk acceptance.

When your existing toolchain is enough

You do not need a new platform merely because developers use an AI coding assistant. Your existing repository, pull-request rules, CI/CD pipeline, application-security tools, and change-management process may be enough when:

• AI contributes small, reviewable changes to an established codebase;
• security requirements and architecture are already documented;
• protected branches and required checks prevent unreviewed releases;
• the team already tests authorization, isolation, and failure paths;
• ownership for operations and vulnerability response is clear;
• audit evidence is retained without manual reconstruction.

In that situation, improve the controls you have. Labeling code as AI-generated does not compensate for weak review, and adopting a governed platform will not fix an organization that routinely bypasses its own gates.

When a governed AI development workflow fits

A governed workflow becomes more valuable when AI is generating whole features or applications, when a prototype must move into production, or when reviewers need traceability across requirements, schema, code, and release approval.

Dual7's two modes separate fast exploration from governed production delivery on the same project. Vibe Mode is for rapid prototyping. Governed Mode takes a feature through Requirements, Plan, UX, Schema, Stories, Build, and Publish stages with approval checkpoints and an audit trail. Dual7's security page says certified changes are reviewed for authorization, validation, and exposure before they can ship, and a person signs off before production.

Whole features or applications move from AI prototype to production, and reviewers need traceable requirements, schema decisions, code, checks, and approvals.

AI contributes small changes inside a mature SDLC with enforced pull-request review, proportionate security testing, owned deployment, and durable evidence.

No platform replaces your threat model, independent testing where warranted, runtime monitoring, incident response, or accountable risk acceptance.

A governed workflow is a fit when you need to keep the speed of an AI-built prototype without treating the prototype as production-ready; make security and approval artifacts part of the build process; design multi-tenancy, access control, and auditability into the application; hand reviewers an owned codebase and traceable change history; or deploy through your Git and onto infrastructure you control.

It is a weaker fit for a tiny isolated script, when your current SDLC already supplies the same evidence, or when you only want inline code completion. Review how Dual7's governed delivery workflow operates before deciding whether its agents and approval points match your process.

Prototype quickly. Make production earn approval.

Dual7 keeps rapid Vibe Mode and governed production delivery on the same project. Evaluate the security controls, approval gates, code ownership, and deployment model against your own release requirements.

Questions to ask any AI code platform before production use

• Can we inspect and export the complete source, dependency files, migrations, and infrastructure configuration?
• Which security checks run, at which stage, and what exactly blocks a release?
• How are authentication, authorization, tenant isolation, and audit logging implemented and tested?
• Where do prompts, source code, credentials, artifacts, and logs go? How long are they retained?
• Can the vendor access production data or make production changes? How is that access approved and recorded?
• Can we use our own Git, cloud, database, scanners, and release controls?
• What evidence connects a requirement to the deployed revision and its approvals?
• Which certifications are complete, which are in progress, and what is in scope?
• How do we leave the platform, rebuild the software, and continue patching it?

Start with the Dual7 security overview or contact the team.

A release rule your team can adopt today

Do not ask, “Was this code written by AI?” Ask, “Can we prove this change satisfies an approved requirement, respects every trust boundary, passed proportionate verification, and was approved by an accountable person?”

If the answer is documented and reproducible, AI-generated code can move through the same release system as any other code. If the answer depends on confidence in the generator, the feature is not ready for production.

Frequently asked questions

Sources

• Dual7 security
• Dual7: How it works
• NIST SP 800-218: Secure Software Development Framework
• OWASP Application Security Verification Standard
• GitHub Copilot responsible-use guidance

Dual7 product and security claims were checked against the public pages above on September 9, 2026. Product details and assurance status can change; verify them during procurement.