AI-generated code demands security controls before the first line

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Apiiro's blog post: AI-generated code is outpacing detection-heavy AppSec, and security controls need to intervene before code is created.

Why it matters: For IAM, NHI, and application security teams, the key issue is governance at the point of generation, where architecture, policy, and context can shape what gets written before it becomes risk.

By the numbers:

• More than 25% of new code at Google was being generated by AI in Q3 2024, according to Apiiro.
• By Q4 2025, that number had doubled to roughly 50%, according to Apiiro.

Context

AI-generated code changes the security problem because the point of risk creation moves earlier in the software lifecycle. Traditional AppSec assumes humans write code first and controls inspect it later, but machine-generated output can produce vulnerabilities before a reviewer ever sees the line. That shifts the governance question from how to detect more issues to how to prevent unsafe code from being produced in the first place.

The identity angle is indirect but real. When AI systems generate code, they act as non-human contributors inside the delivery pipeline, and their outputs can embed insecure access patterns, weak secrets handling, or unsafe API use at scale. For teams that manage IAM, NHI, or application governance, the operational challenge is controlling the policies and context that shape machine-generated code, not merely scanning the result.

Google’s rise from more than 25% AI-generated new code in Q3 2024 to roughly 50% by Q4 2025 is not an isolated data point. It is a typical signal of where enterprise software development is heading, with security teams forced to govern generation rather than only review artefacts after build time.

Key questions

Q: How should security teams prevent vulnerable code when developers rely on AI coding assistants and agentic tools?

A: Security teams should move controls into the development flow before code is written. The practical approach is to combine contextual policy enforcement, architecture awareness, and real time prompt rewriting so AI outputs are constrained by security and compliance requirements. That reduces remediation backlog, lowers triage noise, and prevents vulnerabilities from entering the SDLC in the first place.

Q: Why do AI-generated code changes increase application security risk?

A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.

Q: What breaks when application security stays reactive in AI-driven development?

A: Reactive application security breaks down when teams depend on scanning and fixing after code is already committed. In fast AI-driven workflows, that model creates unresolved findings, repetitive manual triage, and fixes that may not fit the code’s intent or architecture. It also leaves security teams chasing a moving target instead of preventing risky code from ever entering the pipeline.

Q: How should teams govern AI assistants that can run migrations and execute code?

A: Treat those assistants as governed non-human identities with narrowly scoped tool permissions, explicit environment boundaries, and logged execution paths. Separate code generation from runtime execution so the model cannot turn advice into action without the right context, approval, and traceability. If the assistant can touch production-like systems, it needs the same scrutiny as any other privileged automation.

Technical breakdown

Why detection-heavy AppSec breaks at AI coding speed

Traditional application security was built around human-paced development, where scanners, reviews, and tests could intervene after code was written. AI coding assistants compress that window. If a feature is produced in minutes, static analysis and penetration testing become late-stage controls that may still be useful, but they no longer define the primary safeguard. The technical shift is from finding vulnerabilities in artefacts to shaping generation inputs so unsafe patterns are less likely to emerge.

Practical implication: move security controls into the development workflow before code generation, not just into post-commit review.

Prompt-level controls for AI-generated code

Prompt-level control means security context is injected before the model produces output. That context can include approved architecture patterns, policy constraints, threat context, and coding guardrails. In practice, this is closer to policy enforcement than to scanning. The model is still generating code, but the generation space is narrowed by organisational rules and architecture-aware guidance, which is materially different from downstream remediation.

Practical implication: define which architectural and security constraints must accompany every AI coding request.

Architecture-aware guidance for application and NHI governance

AI-generated code often touches APIs, secrets, service credentials, and integration logic, which makes the security problem broader than code quality alone. When generation tools understand how systems are built across application, cloud, and infrastructure layers, they can reduce insecure defaults at source. That matters for NHI governance because machine-generated code can create new service accounts, tokens, or access paths with little human scrutiny. The control question becomes whether generation respects identity and privilege boundaries already in place.

Practical implication: tie AI coding governance to architecture and identity policy so generated code cannot invent risky access patterns.

Threat narrative

Attacker objective: The practical objective is not a single exploit chain but the mass introduction of insecure code paths that weaken application and identity controls at scale.

1. Entry occurs when a developer uses AI coding assistance to generate application code at machine speed, reducing the time available for human review before insecure logic is introduced.
2. Credential or access misuse can be embedded when the generated code handles APIs, tokens, or service credentials without the right architectural constraints or policy context.
3. The resulting application can ship with insecure dependencies, weak controls, or unsafe access paths that persist into runtime and broaden the attack surface.
4. Impact is cumulative, because vulnerabilities are created faster than manual review can remove them, increasing the volume of exposed application and identity risk.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-generated code creates a governance problem before it creates a vulnerability problem: the security decision now happens at prompt time, not after merge. That shifts AppSec from an evidence-based review model to a policy-enforced generation model, which is a material change for enterprise control design. Security leaders should treat this as a new control plane, not a tooling tweak.

Prompt-level security is the new control boundary: once code is produced at machine speed, downstream scanning can only triage damage, not prevent creation. The field needs to recognise that architecture-aware guidance, policy constraints, and threat context are the controls that matter when generation itself is the risk amplifier. Practitioners should govern the inputs to AI coding systems as carefully as they govern production access.

AI coding tools are becoming non-human participants in software delivery: that makes them a governance object, not just a productivity aid. The same identity logic that applies to NHIs now applies to code-generating systems that can instantiate new access patterns, dependencies, and integration paths. Security teams should align AI coding governance with application, cloud, and identity controls before those outputs reach runtime.

Detection-first AppSec is becoming a lagging indicator: the more code AI generates, the more security findings will arrive after the decision has already been made. This does not eliminate scanners, but it changes their role from primary defence to secondary assurance. Practitioners should re-baseline risk ownership around generation controls, not only remediation queues.

AI-generated code security debt will accumulate fastest where architecture context is weakest: generic prompts produce generic risks. When the generation workflow lacks system context, teams inherit invisible design choices that are expensive to correct later. The practical conclusion is clear: security architecture must be encoded into the generation path, or AppSec will keep paying interest on machine-speed development.

What this signals

AI-generated code governance is now a lifecycle issue, not a review issue: the more development shifts into model-assisted generation, the more security leaders need controls that operate before code exists. For practitioners, that means treating prompts, architecture constraints, and policy context as enforceable inputs to the SDLC rather than informal guidance.

Machine-speed development exposes a familiar identity lesson: when non-human systems create high-impact artefacts, governance must move to issuance time. In this case, the artefact is code rather than a credential, but the control logic is similar. Security teams should align AI coding workflows with identity and access policy so unsafe patterns do not become runtime defaults.

For practitioners

• Embed security policy into AI coding prompts Require approved architectural and security context in every prompt that uses AI to generate application code, especially where APIs, tokens, and service credentials are involved.
• Classify AI coding systems as governance objects Assign ownership for the policies, approved patterns, and exception handling that govern code-generation workflows, rather than leaving AI assistant usage to developer discretion.
• Prioritise preventive controls over post-commit review Treat SAST, SCA, and testing as important assurance layers, but move the primary control point earlier so insecure patterns are blocked before code exists.
• Bind AI-generated code to architecture standards Document the service, cloud, and identity patterns that AI assistants may use so generated code cannot invent unauthorised access paths or unsafe defaults.
• Review machine-generated access patterns for NHI impact Look for new service accounts, tokens, or integration credentials that appear because code was generated automatically and ensure they follow the same governance as any other non-human identity.

Key takeaways

• AI-generated code is forcing AppSec to shift from late-stage detection to pre-generation control because code now appears faster than human review can keep up.
• The governance challenge is not only code quality. It is controlling the prompts, architecture context, and policy signals that shape what the AI writes.
• Security teams should treat AI coding systems as part of the delivery control plane and bind them to identity, architecture, and application security standards.

Key terms

• AI-generated code: Code produced wholly or partly by a model-based coding assistant rather than written line by line by a human. The security issue is not the generation itself, but the speed and scale at which risky patterns can enter the software lifecycle before review catches up.
• Prompt-level security control: Prompt-level security control is the practice of governing what an AI system can do through the instructions it receives. It applies policy, filtering, validation, and guardrails to user prompts and system prompts so the model is less likely to reveal sensitive data, execute unsafe actions, or follow malicious instructions.
• Detection-heavy AppSec: An application security operating model that relies primarily on scanning, testing, and review after code exists. It remains useful for assurance, but it is poorly matched to machine-speed generation because it discovers issues after the design choice has already been made.
• Architecture-aware guidance: Security direction that reflects how a real environment is built, including services, APIs, cloud dependencies, and identity boundaries. In AI-assisted development, this matters because generic advice cannot reliably prevent insecure patterns in complex systems.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that helps teams adapt identity controls to AI-driven delivery. It is designed for practitioners who need to connect identity governance to real-world security operations.