AI writes code faster, but application security is falling behind

At a glance

What this is: Arxan Technologies argues that AI is now accelerating both software production and attack capability, creating a tighter gap between vulnerability creation and exploitation.

Why it matters: For IAM and security practitioners, this matters because AI-driven development and AI-assisted attack workflows change how quickly access controls, code reviews, and runtime protections must adapt across application and identity pathways.

By the numbers:

• ~90% of Fortune 100 companies are using AI coding tools.
• ~40–50% of code is now AI-generated in many environments.
• 83% of applications are under constant attack, according to the vendor's 2025 threat report.

👉 Read Arxan Technologies' analysis of AI-driven code generation and application attack speed

Context

AI-assisted software development is shifting the security problem from slower human-coded release cycles to a much faster production model where vulnerabilities can be introduced at machine speed. In parallel, attack tooling is also accelerating, which means traditional review, scanning, and patching rhythms are losing effectiveness. The application security question is no longer whether teams can find issues eventually, but whether they can keep up with the speed of creation and exploitation.

This matters to IAM and NHI practitioners because modern software pipelines depend on identities everywhere: developer credentials, CI/CD tokens, service accounts, API keys, and runtime permissions. When code generation accelerates and release processes remain partly manual, identity controls become part of the attack surface rather than just the access layer. The article's starting position is typical for large enterprises now facing AI adoption across engineering teams.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: Why do AI-assisted attacks reduce the value of traditional patching windows?

A: Because AI can compress reconnaissance, exploit development, and adaptation into a much shorter timeline than manual attacker workflows. Once exploitation can begin within minutes or hours of exposure, periodic patch cycles no longer provide enough protection on their own, especially for internet-facing applications.

Q: What breaks when mobile runtime protection is missing?

A: Attackers gain a cleaner path to study and manipulate the app in real time, which makes reverse engineering, hook-based probing, and certificate interception much easier. That increases the chance that backend APIs will be abused through modified clients or replayed sessions, especially for support and account-control flows.

Q: What does this shift mean for application security and IAM teams?

A: It means application security and IAM can no longer operate as separate workstreams. AI-generated code still depends on identities, secrets, and release permissions, so governance must cover the code path and the identity path together. Otherwise, the same acceleration that helps developers also helps attackers.

Technical breakdown

Why AI-generated code increases application attack surface

AI coding tools can produce large volumes of code quickly, but they do not guarantee secure design, complete threat modeling, or correct control selection. That creates a scaling problem: insecure patterns can be replicated across repositories faster than traditional review can catch them. The risk is not only flawed logic, but also invisible assumptions about authentication, secrets handling, input validation, and authorization boundaries. In large environments, this turns code generation into a control-amplification problem where the same weakness can be copied into many services before detection.

Practical implication: security teams need guardrails that operate during code creation, not only after merge or release.

How AI changes attacker speed and exploit development

The article describes a world where AI can identify vulnerabilities, reverse engineer applications, and generate exploits with minimal human input. That matters because exploit development is no longer limited by manual research and scripting cycles. Once attackers can automate reconnaissance and adaptation, the time between disclosure, proof of concept, and weaponisation collapses. Defenders then face a shorter response window and more varied attack paths, including swarm-style activity that increases pressure on runtime controls.

Practical implication: teams should assume exploitation may begin before normal patch and triage workflows complete.

Runtime application protection as a compensating control

The article points to obfuscation, anti-tampering, RASP, and white-box cryptography as runtime protections that move defence closer to the application itself. These controls do not replace secure development practices, but they help reduce the value of reverse engineering and slow certain exploit chains once code is in production. Their role becomes more important when the external environment is hostile and the operating context is not fully owned by the application team, as with mobile and web deployments.

Practical implication: runtime controls should be prioritised for exposed applications where external attackers can probe continuously.

Threat narrative

Attacker objective: The attacker objective is to discover and weaponise application weaknesses quickly enough to exploit systems before defensive review and remediation can catch up.

1. Entry begins when AI-assisted attackers use automated reconnaissance to identify exposed applications, weak logic, or reverse-engineerable code paths at scale.
2. Escalation follows when exploit generation is automated and vulnerabilities are weaponised faster than defenders can complete review, patching, or release gating.
3. Impact occurs when applications are probed continuously, exposed controls are bypassed, and the organisation loses time to respond before exploitation spreads.

NHI Mgmt Group analysis

AI has turned application security into a speed problem, not just a vulnerability problem. The article is right to emphasise that the window between code creation and exploitation is collapsing. That means security programmes that still depend on periodic review are structurally behind the threat. The operational question is how to enforce controls at the same pace as code generation and attack automation.

AI-generated code creates governance debt because the code owner may not fully understand what was produced. That is not just a software quality issue. It affects who can review, attest, and sign off on runtime behaviour when developer intent and machine output diverge. Practitioners should treat provenance, approval, and release accountability as part of application governance, not an afterthought.

Runtime defence is becoming a necessary compensating control for exposed applications. When attackers can decompile, probe, and adapt quickly, perimeter-only security loses value. Controls such as RASP and anti-tampering matter because they reduce attacker feedback and raise the cost of live analysis. The practical conclusion is that protection must follow the application into runtime, especially for internet-facing services.

Identity controls now sit inside the application attack story. AI-generated software still depends on secrets, tokens, service accounts, and pipeline identities, which means NHI governance is part of appsec resilience. The more code is generated automatically, the more important it becomes to govern the credentials and authorisations that let that code build, deploy, and call downstream services. Teams should align application security with NHI lifecycle control, not treat them as separate programmes.

Application self-defence is becoming a named strategic concept for AI-era software risk. The article's underlying message is that some applications now need to resist active probing in production, not just survive pre-release testing. That shifts the conversation from compliance scanning to runtime survivability. Practitioners should design for software that can endure machine-speed attack pressure, not merely pass a checklist.

What this signals

AI-generated code should now be treated as an identity-bearing workload. The practical reason is simple: every new build path introduces credentials, permissions, and service dependencies that can be abused if they are not lifecycle-managed. Teams should expect the next wave of appsec work to sit at the junction of secure development, secret governance, and release authority.

The market signal is that security teams will need better runtime evidence, not just better scanning. When code velocity rises faster than review capacity, the controls that matter most are the ones that survive production pressure and reduce attacker dwell time. That shifts programme investment toward release governance, runtime containment, and NHI lifecycle control.

For practitioners

• Embed security checks into AI-assisted development workflows Add policy and validation steps into coding copilots, pull requests, and CI/CD gates so insecure patterns are flagged before merge, not after deployment.
• Prioritise runtime protection for internet-facing applications Deploy obfuscation, anti-tampering, and RASP where exposed applications are likely to be probed continuously and cannot rely on perimeter controls alone.
• Inventory pipeline identities and secrets Map developer accounts, service accounts, tokens, and API keys that enable code build and release, then reduce standing access and tighten rotation.
• Shorten detection-to-response workflows Rework triage and patching so exploit signals can be acted on before normal release cycles complete, especially for high-exposure applications.

Key takeaways

• AI coding tools are now widespread enough to change the security baseline for enterprise software delivery.
• The defensive gap is shrinking because attackers can now move from discovery to exploitation much faster than human-paced workflows were designed to handle.
• Security programmes need runtime protection, tighter pipeline identity governance, and faster response paths to keep pace with machine-speed development.

Key terms

• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• 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.
• Application self-defence: A strategy that assumes applications will be continuously probed and therefore need built-in protective behaviour. It shifts security away from relying only on external scanning and perimeter tools, and toward controls that remain active inside the application during runtime.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full article

Arxan Technologies' full blog covers the operational detail this post intentionally leaves for the source:

• Specific application self-protection mechanisms, including obfuscation, anti-tampering, and runtime application self-protection implementation patterns.
• The article's own threat and attack-rate data by industry, which can support board reporting and appsec prioritisation.
• Additional discussion of how AI-generated code changes release governance, testing bottlenecks, and security accountability in large software organisations.

👉 The full Arxan Technologies post covers runtime protection, application self-defense, and the attack-surface shift in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with modern software delivery and runtime risk.