AI Code Security: A Three-Tier Model for Secure AI-Generated Code

A working framework for AI code security, reasoning about where AI coding agents get security right by default, where they need a nudge and where gaps remain.

The conversation about AI code security and AI-generated code has, so far, been organized around a simplistic set of assumptions. Either AI-generated code is highly risky, in which case it needs aggressive review, or it is safe enough, in which case the current development workflow already handles it. Both framings are too coarse to drive useful insights.

A year of running coding agents against real and synthetic vulnerability prompts has shown us that the issues come in at least three structurally different tiers. Each tier has a different relationship to review, a different cost of remediation, and a different failure mode when controls are mismatched. This working framework is useful enough that AppSec teams can use it today to decide where their controls should sit and to understand why some interventions work while others do not.

The rest of this post walks through each tier with examples, explains why each behaves the way it does, and lays out what AppSec teams should do with the model.

Tier 1: unconditionally active priors

Tier 1 is the good news of AI coding. There are security primitives that stock coding agents apply by default, with no special prompting, no adversarial review and no codebase signal that the agent is being judged on safety. It’s the equivalent of a well-trained junior developer who knows the basics of secure application development cold.

Concrete examples we observed consistently include:

• Password hashing with bcrypt, including reasonable cost parameters. Ensures that even if the database is breached, stored passwords remain computationally expensive to crack, buying users time to rotate credentials before attackers can recover them.
• Token generation through crypto.randomBytes rather than Math.random or any similar weak randomness primitive. Produces session identifiers, reset links and API keys that attackers can’t easily predict or reproduce, keeping the underlying credentials unguessable.
• AES encryption with fresh GCM initialization vectors per message. Preserves both the confidentiality and integrity guarantees of the encryption, so each message stays protected and forgeable.
• Constant-time comparison through timingSafeEqual when the agent needs to compare a user-supplied value to a secret. Compares secrets in a way that reveals nothing through response timing, closing off a side channel that would otherwise let attackers reconstruct tokens or signatures incrementally.
• Expiry checks on tokens, sessions and confirmation flows. Bounds the useful lifetime of every credential, so a stolen token or leaked reset link becomes worthless once its window closes rather than granting indefinite access.
• Guard rails on user-enumeration paths, like uniform responses on login failure. Keeps account existence private by returning consistent responses, denying attackers the confirmed target list they would use to focus credential-stuffing and phishing campaigns.

These best practices are implemented reliably by the coding agents we have observed. They show up regardless of whether the spec mentions security at all, or whether the codebase already uses other safe primitives, and they show up in the first round, before any reviewer has weighed in.

Why this works is straightforward. These primitives are densely associated with their domain in the training data. When the agent is asked to hash a password, the canonical pattern is bcrypt. When it is asked to generate a token, the canonical pattern is crypto.randomBytes. The agent has, in effect, memorized "if you are doing X, you do it with Y," and Y happens to be the safe choice. The pattern strength is high enough that the agent does not deviate even when the prompt is sloppy.

The implication for AppSec teams is that the Tier 1 surface is mostly well addressed by modern AI coding agents and brings little risk to production environments. It’s worth performing inexpensive spot-checking to uncover any outliers, but it’s not worth investing significant review budget to hunt for vulnerabilities that aren’t there.

Tier 2: conditionally dormant knowledge

Tier 2 is where most of the interesting work in AI code security currently lives. These are issues the agent has the knowledge to handle, but does not handle by default. In these cases, a single hint in the prompt is generally enough to activate the full mitigation. Adversarial review surfaces and corrects the gap reliably.

A number of Tier 2 findings appear consistently in our research, each with a recognizable failure mode when the coding agent is asked to implement a related feature:

• Server-Side Request Forgery (SSRF): Asked to build a URL fetcher with no further direction, the agent generally produces a naive implementation that takes any URL the user submits and fetches it. This opens a server-side request forgery hole, letting attackers pivot through the server to reach internal services, cloud metadata endpoints and other resources the application was never meant to expose.
• Path traversal: Asked to build a file-read endpoint, the agent produces one that concatenates the user-supplied filename onto a base directory and reads whatever the resulting path resolves to. This enables path traversal, so an attacker supplying sequences like ../../ can escape the intended directory and read arbitrary files such as credentials, configuration, or system files.
• Insecure deserialization: Asked to deserialize user input, the agent produces a pickle.loads call. This grants remote code execution, because a crafted pickle payload runs attacker-controlled code the moment it is deserialized, effectively handing over the process.

Other commonly observed Tier 2 findings include server-side template injection, XML external entity attacks, broken authorization, mass assignment and CSV formula injection.

Each of these also has a recognizable fix mode. Add a single sentence to the prompt, "validate the URL," and the agent produces a layered SSRF defense. Add "validate the path," and the agent produces a path-traversal check that resolves the path against an allowed base and rejects anything outside it. Add "deserialize safely," and the agent produces JSON parsing or a typed schema. The knowledge was always there. It was dormant, waiting for activation.

Adversarial review reliably activates Tier 2 knowledge. In our research, one round of review against a Tier 2 vulnerability produces a comprehensive mitigation in the vast majority of cases. Two rounds are enough to handle the edge cases. This is the area where multi-round review pays off most clearly. The reviewer is not surfacing techniques or insights the agent does not know. The reviewer is prompting the agent to apply knowledge it already has.

The implication for AppSec teams is that Tier 2 is the right home for adversarial-review investment. Configure a panel of reviewers focused on the classes above, run them against agent-generated code, and most Tier 2 issues will be caught and fixed. This comes with a real cost; additional review rounds use time and tokens, but the return is high. Out of the broad center of AI-generated vulnerability patterns, Tier 2 is the most addressable.

Tier 3: knowledge gaps

Tier 3 is where the model gets interesting and where most of the unsolved AppSec work lives. Tier 3 issues are ones the agent and its reviewers do not handle by default, even after extensive adversarial review, because the fix requires specific factual knowledge that the reviewer simply doesn’t have.

Tier 3 splits into two sub-tiers, which are worth distinguishing because the controls for each are different.

• Tier 3a, business-logic invariants: These findings cover instances when the code is spec-compliant but includes logically unsafe behaviors. Examples include accepting a negative quantity in a financial transfer, allowing self-referral loops in an invite system, or accepting integer values that overflow when used in arithmetic.

The fix for these requires reasoning about the system as a whole, not memorizing a single fact. Tier 3a issues are tractable for adversarial reviewers, because the reviewer can often spot the flaw by working through the code, but in our observations they are not surfaced reliably without a review that specifically targets business logic. They require a reviewer to be prompted to ask what invariants this code violates when called in unexpected ways.

• Tier 3b, specific factual lookups outside the reviewer's training distribution: These are cases where recognizing the unsafe pattern depends on knowing a particular fact rather than reasoning through the code. Examples include
• The Azure metadata endpoint at 168.63.129.16: A reviewer who does not recognize this address as the cloud metadata service will not flag code that fetches it, missing a server-side request forgery path that can expose credentials and instance data.
• Recent CVEs that have not yet entered the training corpus in volume: If the reviewer has no knowledge of a third-party vulnerability, it cannot connect a vulnerable library version or code pattern to the known flaw, so the issue passes review as ordinary code.
• Vendor-specific authentication flows: Where the safe pattern requires knowing one provider's particular quirks. Without knowing how a given provider expects tokens to be validated or scoped, the reviewer can approve a flow that looks reasonable in general but is exploitable against that specific service.
• Updated crypto parameter recommendations where the safe value has shifted over time: A reviewer working from older guidance will treat a now-weak parameter as acceptable, as with NIST's 2023 revision moving the recommended PBKDF2 iteration count from 100,000 to 600,000, where the lower value no longer offers the intended resistance to brute-force attacks.

Tier 3b is where multi-round review fails most clearly. The reviewer does not have the facts it needs to generate the findings. No amount of adversarial pressure across rounds will produce knowledge the reviewer never held to begin with. Multi-round review converges on the boundary of what the reviewer already knows, and Tier 3b issues sit, by definition, outside that boundary.

The control surface for Tier 3 is fundamentally different from Tier 2. Tier 3a requires reasoning-focused review, often by a reviewer prompted specifically on business-logic invariants rather than vulnerability classes. Tier 3b requires external knowledge injection. The reviewer needs access to current threat intelligence, current CVE feeds, vendor documentation, or cloud-provider quirks, depending on the specific factual gap.

Neither of these controls is automatic in most AI code review pipelines today. AppSec teams that are running Tier 1 and Tier 2 controls without a Tier 3 layer have a hole in their pipeline that the pipeline itself cannot detect.

Why the tiers matter

A team that invests heavily in adversarial review on Tier 1 is wasting budget. The agent gets Tier 1 right without help. The review rounds look for issues that aren't there, find nothing useful, and consume significant time and tokens.

A team that skips specific hints to address Tier 2 issues is leaving easy mitigations on the table. The hint approach works best when the prompt is under the AppSec team's control, as they have the most experience with where security controls can fail and the best practices for addressing the gaps. Adversarial review is the right control for Tier 2.

A team that runs five rounds of adversarial review and certifies the result as "secure" without external knowledge augmentation is almost certainly shipping Tier 3 issues. The pipeline's own framing of its work is misleading. The convergence point is not safety. It is the reviewers' working memory.

The right shape of an AI code security program is layered. Tier 1 accepts the agent's defaults and spot-checks to find outliers. Tier 2 introduces adversarial review with reviewers focused on specific vulnerability classes. Tier 3a brings business-logic-focused reviewers operating on the system as a whole. And finally, Tier 3b brings knowledge augmentation through threat-intel feeds, CVE databases, cloud documentation and current standards references.

Each layer requires a different investment, a different review prompt, and a different evaluation approach. Bundling them under "we run AI code review" obscures whether the pipeline is actually addressing the issues the team is paying it to address.

Putting the model to work

For an AppSec leader picking up this framework, here is a short list of starting moves:

1. Audit your existing AI code review controls and tag each one with the tier it is addressing. If most controls are stacked on Tier 1, the program is overpaying. If none are on Tier 3, the program has a quiet gap.
2. Build a Tier 3b knowledge surface before you need it. A small, curated list of facts the reviewer should always have at review time. Start with the cloud metadata IPs of the three major providers. Add the current crypto parameter recommendations from NIST and OWASP. Add the most recent thirty CVEs in your stack. The list does not need to be exhaustive; it needs to exist and be refreshed.
3. Run a Tier 3a reviewer separately from your Tier 2 panel. Use a reviewer prompt focused on invariants and unexpected inputs, not on vulnerability classes. The findings will look different. That is the point.
4. Watch for Tier confusion in vendor pitches. If a vendor describes their AI review product as "we catch everything," ask what tier they are catching. If the answer is unclear, it's probably Tier 1 and Tier 2.

Closing

A three-tier model gives AppSec teams a vocabulary to ask the right questions about an AI code review pipeline. Which tier is this control addressing? Is the control the right shape for the tier? What is the pipeline silently missing? The questions are simple, but the answers are not always comfortable.

We have used this framework internally to make decisions about where to invest in our own research, and it has held up. It is not finished, but we think it is the right shape for the conversation the AI code security community needs to have over the next year.

Key takeaways

• Tier 1 (unconditionally active priors): Security primitives like bcrypt hashing are applied by AI agents automatically; they require minimal oversight and are well-addressed by default.
• Tier 2 (conditionally dormant knowledge): Vulnerabilities like SSRF and path traversal are fixable by the agent if prompted; this tier is the optimal target for adversarial review investment.
• Tier 3a (business-logic invariants): Complex logic issues (e.g., overflows) require reasoning-focused review that specifically targets system-wide invariants rather than standard vulnerability classes.
• Tier 3b (factual lookups): Issues involving external knowledge (e.g., specific CVEs or cloud metadata) cannot be solved by multi-round review alone; they require external knowledge injection.
• Layered security strategy: Effective AppSec programs must tailor their controls to each tier rather than relying on one-size-fits-all "AI code review" tools that often ignore Tier 3 gaps.
• Investment efficiency: Teams overpay when stacking review resources on Tier 1; shift budget toward Tier 2 adversarial panels and Tier 3 knowledge augmentation.
• Vocabulary for pipeline evaluation: The three-tier model provides a necessary framework to challenge vendor pitches and identify where an AI code security pipeline is silently failing.