AI writes code faster, but application security is falling behind

At a glance

What this is: Arxan Technologies argues that AI is accelerating both software creation and exploitation, making application security operate at machine speed rather than review cycles.

Why it matters: This matters because IAM, PAM, and NHI programmes increasingly depend on applications that are changing faster than traditional security review, which raises the stakes for runtime controls and secure release governance.

By the numbers:

• ~90% of Fortune 100 companies are using AI coding tools.
• ~40-50% of code is now AI-generated in many environments.

Context

AI-generated code changes the security problem because the pace of software change now outstrips the cadence of manual review and release governance. When code is produced faster than teams can test, secure, and observe it, vulnerabilities can move from introduction to exploitation before conventional controls finish their cycle.

The identity angle is indirect but real: modern applications are bound to service accounts, API keys, tokens, and other machine credentials, so insecure code and fast release pipelines can expand the blast radius of NHI mismanagement. In practice, the governance gap is not just code quality; it is whether runtime identity and application controls can keep up with machine-speed development.

This is an application security and software delivery problem first, and a broader identity security issue when those applications mediate access for users, workloads, and agents.

Key questions

Q: What breaks when AI coding agents are allowed to ship code without security constraints?

A: Teams get working software that can still carry old, well-known vulnerabilities back into production. The failure is not only a coding mistake. It is a governance failure where functional correctness is treated as sufficient evidence, even when the agent has reintroduced a flaw that the security community already fixed.

Q: Why do AI-assisted attacks increase risk even when teams still run vulnerability scans?

A: Because the attacker’s cycle can now be shorter than the defender’s scan-and-remediate cycle. Scans identify weaknesses, but they do not stop exploitation that happens before the next review window. The practical answer is to combine detection with runtime resistance and strong release rollback capability.

Q: Why do service accounts and API tokens make application exploits worse?

A: Service accounts and API tokens extend a host compromise into other systems because they carry machine authority beyond the vulnerable process. If those identities are overprivileged or long-lived, the attacker can pivot from code execution to persistence, data access, or cloud control. NHI governance is therefore part of incident containment.

Q: Should security teams prioritise runtime application protection or better code review first?

A: They should treat them as complementary controls, but runtime protection becomes more urgent when release cycles are fast and applications face active probing. Better code review reduces defect introduction, while runtime controls reduce exposure after defects inevitably slip through. The right priority depends on how quickly the application can be attacked after release.

Technical breakdown

Why AI-generated code changes the application security control point

AI-assisted development shifts the security question from whether developers wrote a vulnerable pattern deliberately to whether insecure logic was introduced at the speed of automation. That matters because code review, static scanning, and release gates all assume a human-paced pipeline with time for inspection and remediation. When code generation is continuous, weaknesses can be replicated across repositories and services before teams understand the pattern. The control point therefore moves closer to build-time policy, automated verification, and runtime enforcement, especially where applications handle credentials, authorization, or transaction flow.

Practical implication: move security checks earlier in the pipeline and treat runtime enforcement as a required backstop.

Why attack speed now outruns periodic scanning and patching

The article’s core security claim is about asymmetry. Attackers can use AI to identify flaws, reverse engineer applications, and generate exploitation attempts faster than defenders can rely on periodic scans or scheduled patch windows. That breaks the old assumption that defenders always have a usable response interval. In practice, the relevant control is not just detection, but how quickly the application can resist tampering, expose suspicious behaviour, and limit impact while security teams respond. Runtime application self-protection, obfuscation, and anti-tampering exist for this reason.

Practical implication: evaluate whether your applications can resist active probing between release cycles, not just after the next scan.

How machine identities amplify the blast radius of insecure code

The identity intersection is where this topic becomes more than a generic appsec story. AI-generated code often interacts with service accounts, APIs, and automation tokens, which means insecure patterns can expose privileges that persist outside the application itself. If a flawed workflow leaks a secret, over-broad access token, or weak authorization check, the resulting risk is not just code compromise but privilege abuse through a non-human identity. That is why application security and NHI governance now overlap in the same operational path.

Practical implication: align application review with NHI credential scope, token hygiene, and authorization boundaries.

Threat narrative

Attacker objective: The attacker wants to turn machine-speed code generation and analysis into faster exploitation, broader access, and higher-volume compromise.

1. Entry begins with AI-assisted reconnaissance or code analysis that identifies vulnerable logic faster than human review can keep pace.
2. Escalation occurs when generated exploit chains or malicious automation are applied at scale against exposed applications and their supporting credentials.
3. Impact follows when insecure code, stolen tokens, or weak authorization paths enable broad compromise across applications and connected services.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

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 has created a security governance gap, not just a productivity shift. The central failure is that many development and release controls still assume human review can absorb the risk introduced by software created at machine speed. Once code can be produced, copied, and deployed faster than it can be understood, the organisation is governing velocity without governing trust. Practitioners should treat this as a release-governance problem as much as an appsec problem.

Machine-speed development needs machine-speed enforcement: the control set has to move from periodic review to continuous protection. Static review alone cannot contain applications that are probed, decompiled, and attacked continuously. Runtime controls matter because they reduce the time between weakness introduction and exposure. For security teams, the practical question is whether policy is enforced while the application is running, not only when it is being assessed.

AI-generated code becomes an identity issue the moment it handles secrets, tokens, or delegated access. The article’s real governance implication is that insecure code can enlarge the attack surface around service accounts and other NHIs, especially where access checks are weak or secrets are embedded in workflows. This is where application security and NHI lifecycle governance converge. Practitioners should treat every AI-assisted application path as a potential privilege amplifier.

Security programmes should stop treating AI as only a developer efficiency layer and start treating it as a risk multiplier. The article shows that faster code creation and faster attacks reinforce each other, which invalidates models built around slow remediation cycles. That means security architecture, release governance, and identity controls need to be designed as one operating system for software trust. The practitioner conclusion is straightforward: speed is now a control problem.

Application self-defense is becoming a necessary compensating control, not an optional enhancement. When the attack window collapses, controls such as anti-tampering, obfuscation, and runtime protection become part of baseline resilience rather than specialist hardening. That does not replace secure coding or identity governance, but it does reduce the window in which flaws can be turned into breaches. Practitioners should plan for layered containment, not single-point prevention.

What this signals

AI-generated code has turned software trust into a moving target. Security teams should assume that the rate of change in development now outpaces the rate at which human review can validate logic, secrets, and authorization paths. The practical implication is that release governance, runtime control, and NHI oversight have to operate as a single security system rather than separate programmes.

The near-term signal for practitioners is that application security will be judged less by how many findings are produced and more by how quickly flawed code can be contained after release. Teams that still rely on periodic review will continue to miss the window in which AI-assisted flaws become exploitable, especially where applications mediate access through service accounts and tokens.

For practitioners

• Embed policy checks in the build pipeline Require automated checks for insecure patterns, secret exposure, and authorization logic before code reaches release gates.
• Treat runtime protection as baseline control Use runtime application self-protection, anti-tampering, and obfuscation where applications face direct internet exposure or handle sensitive business flows.
• Review NHI dependencies in AI-assisted applications Map the service accounts, tokens, and API keys that AI-generated components can reach, then constrain their scope to the minimum required.
• Shorten the gap between detection and containment Align scanning, alerting, and release rollback so that a newly introduced flaw can be isolated before it is widely exercised in production.
• Test security assumptions against machine-speed attacks Use adversarial testing to see whether applications, gateways, and controls can withstand rapid exploitation attempts rather than only slow manual probing.

Key takeaways

• AI-assisted development is compressing the time between vulnerability introduction and exploitation, which makes periodic review too slow on its own.
• The article’s strongest security message is that application protection now has to happen at build time and at runtime, not just during testing.
• Where applications depend on service accounts and tokens, AI-generated code becomes an identity governance problem as well as an appsec problem.

Key terms

• AI-generated code: Software produced or materially assisted by AI coding tools rather than written entirely by human developers. The security issue is not the origin of the code alone, but the speed at which weaknesses can be introduced, replicated, and deployed before normal review processes catch them.
• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
• Machine-speed threat: A threat that progresses faster than manual identity controls can reasonably observe or stop. In practice, it turns short-lived access misuse into a governance problem because the window for detection, decision, and revocation may close before the control cycle completes.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader software and access risks that modern development introduces.