Summary
- Xint reports 434 individually validated, exploitable findings across three AI-assisted software-development scenarios.
- Resource exhaustion, broken authorisation, object-level access failures, and secrets exposure were among the most common or severe weaknesses.
- The limited vendor study does not establish a universal defect rate, but its findings support independent testing before AI-generated code reaches production.
Applications created or extensively modified with artificial-intelligence coding tools contained hundreds of validated security flaws in a new study, with failures in availability, authorisation, access boundaries, and secret management appearing across several development approaches.
Xint tested applications produced through three AI-assisted workflows: a new application generated from a detailed specification, a second application requested through a short instruction, and a mature system migrated to a modern architecture before being hardened with AI assistance.
The company says every reported finding was individually validated as exploitable rather than counted directly from automated scanner output. Across the applications, it identified 434 flaws: 196 in the two newly generated projects and 238 in the larger application that had been migrated and hardened.
Resource-exhaustion and denial-of-service conditions formed the largest category, accounting for 93 findings. Authorisation and insecure direct-object-reference weaknesses followed with 88, while access-boundary problems including directory traversal and server-side request forgery accounted for 54.
The research also identified 23 critical-severity findings. Hardcoded or default secrets accounted for 11 of those, while six involved remote code execution through development or debug functionality left accessible in the application.
The study does not establish that all AI-generated software contains the same volume or distribution of weaknesses. Its sample is limited, the assessment was conducted by a security vendor using its own platform, and the tested applications do not represent every model, programming language, framework, prompt, or development team.
The reported defects nevertheless concern controls that depend heavily on application context. Coding models can generate familiar components and connect established libraries, but access decisions still depend on an organisation’s users, roles, tenant boundaries, data classifications, and business processes.
An application may correctly establish that a user is authenticated while failing to determine whether that person can access a particular record, customer account, administrative function, or object belonging to another tenant. Those failures often require an understanding of the intended business rules rather than a syntactic review of individual code fragments.
Resource-exhaustion weaknesses arise through a different route. Code can produce the expected result in a demonstration while permitting unbounded requests, expensive database operations, uncontrolled recursion, synchronous processing, or excessive memory consumption.
Such behaviour may remain invisible during development and functional testing, then appear when the service receives hostile input or ordinary production traffic at a larger scale. Availability limits, request quotas, workload isolation, and failure handling need to be designed rather than inferred from a successful prototype.
Secrets exposure reflects weaknesses in both code and deployment practice. AI tools may reproduce insecure examples, create temporary credentials, or enable debugging functions that support development but should not remain reachable in production.
Developers working at speed may accept an output once the application runs without tracing every generated configuration value, permission, network dependency, or deployment assumption. Reviewers also face a volume problem when AI produces more code than a team can examine thoroughly within the original delivery schedule.
The findings from the migrated application are relevant to organisations using AI to modernise existing systems rather than create isolated prototypes. Migration can change frameworks, authentication libraries, data-access layers, and deployment models at the same time.
Using the same AI-assisted workflow to harden the resulting application does not provide independent assurance. Security testing needs to examine the completed design, including authorisation paths, tenant separation, secret handling, abuse of business logic, dependency exposure, and operational limits.
European product-security requirements are increasing the need to demonstrate secure development, vulnerability handling, and supported software lifecycles. Organisations placing products with digital elements on the market remain responsible for exploitable weaknesses introduced through generated code.
AI-assisted software should pass through the same threat modelling, architecture review, dependency governance, testing, and release controls as code written without such tools. Where the application carries significant operational or regulatory exposure, independent adversarial testing provides separation between the system’s creation and the decision to place it into production.
