Securing a business application built with AI: the risk has moved from the network to the code

A growing share of the code that runs business applications is no longer written line by line by a developer. It is produced with an agent, an assistant, a model that completes, suggests, generates. The gain in speed is real, and it is no longer up for debate. What is up for debate is how the risk is shared: the security assumptions inherited from an era when a contractor wrote the code and the IT department guarded the network no longer hold. Whoever signs off on what ships to production inherits a risk whose centre of gravity has moved, without anyone having decided it.

The reflex would be to add a layer: one more firewall, a network audit, an access review. That reflex protects a perimeter that is no longer where the risk enters. When a team builds with AI, the exposed surface is not the network, it is what enters the codebase: the generated code, the dependencies pulled in to move fast, the pipeline that turns that code into running software. The risk has left the outer boundary and settled into the software supply chain. Securing it means governing it there.

This article maps where the risk actually sits in AI-assisted development, and what governing it demands across three fronts: the code the AI produces, the dependencies it draws in, the pipeline that ships it. Each front calls for a governance decision, not a silver-bullet tool. And for whoever oversees this work, the point is to make the risk measurable without becoming the brake on a team that has, for its part, gained speed.

The risk has changed sides: why the network model no longer protects

For twenty years, securing a business application first meant securing its environment: firewall, virtual private network (VPN), access management, system partitioning. That model remains necessary, it does not become wrong. But it answers one question, how to stop an intruder from reaching the system, that is no longer the only one nor the main one.

The shift is documented. The European Union Agency for Cybersecurity (ENISA), in its analysis of supply chain attacks, states it plainly: strong perimeter protection is no longer enough once attackers turn their attention to suppliers, and an organisation can be vulnerable even when its own defences are sound. The breach no longer comes through the door you guard, it comes through what you assemble.

AI-assisted development amplifies that shift. An agent produces code and pulls in components at a pace and a volume that outstrip manual review. The software supply chain, meaning everything that goes into a piece of software before it runs (the code written, the third-party libraries, the tools that build the application), becomes the surface to watch. It spans the whole lifecycle of an application designed with an agentic AI, from the first suggested line to going live.

For a chief information officer (CIO) as much as for any management team overseeing this work, the consequence is concrete. The security dashboard can no longer stop at access and the network. It has to take in what happens upstream, in the software factory, where the code takes shape and the components come together.

Generated code: plausible is not safe

An agent generates code that compiles, passes the visible tests, and looks remarkably like good code. That plausibility is exactly what lulls vigilance: nothing in the look of a snippet signals that it carries a flaw.

The point is measured. Generation models learn on vast volumes of public code, which also contains vulnerable code. A study presented at the IEEE Symposium on Security and Privacy (Pearce et al., 2022) put a generation assistant through eighty-nine scenarios built around the most dangerous weaknesses catalogued by the CWE (Common Weakness Enumeration, the reference taxonomy of software flaw types). Of the 1,689 programs produced, nearly 40% contained a vulnerability. The figure applies to a precise protocol, not to a universal truth, but the order of magnitude is enough to frame the problem: an agent’s output is not safe by default.

A complementary piece of work points to a more insidious effect. A Stanford study (Perry et al., 2023) showed that developers with an AI assistant wrote less secure code than those without one, whilst being more convinced they had produced secure code. That false confidence is the real danger for a management team: it makes the risk invisible to the very people producing it, and it drops vigilance at the moment it would be most useful.

The answer rests on a simple governance principle. Code review is no longer an optional comfort, it becomes a security link again. Not a line-by-line reading of everything, impractical at the volume of AI, but a review targeted at the sensitive surfaces: input handling, secrets management, authentication, outbound calls. The skill is not knowing how to write the code, it is knowing how to read and question what a machine has written, keeping in mind that the structural soundness of code is inseparable from its security. Practising the same tools on the production side, every day, is what makes it possible to know where to look.

Dependencies: the blind spot in the software supply chain

To move fast, a developer, or the agent assisting them, pulls in a third-party package rather than rewriting a function. That is legitimate and it is massive. But the provenance and security state of that package are rarely checked at the moment it enters the project.

The OWASP reference ranks vulnerable and outdated components among the ten leading application risks. The point it makes is simple and often ignored: you inherit the risk of code you did not write, and a single unpatched dependency can expose the whole application, all the more so because these components generally run with the same privileges as it does. Add to that a rarely examined reality: one library pulls in others, its transitive dependencies, so the real surface is far wider than the list of packages chosen explicitly.

The AI-assisted context opens a further, novel door. In its 2025 threat landscape, ENISA documents the targeting of the supply chain through booby-trapped packages and flags vectors tied directly to development assistants, as far as injecting malicious instructions into their configuration files. When a model suggests a component name, nothing guarantees that the component is legitimate, nor even that it existed before an attacker registered it to catch an expected suggestion.

Governing dependencies means putting three disciplines in place. Knowing what comes in, through an inventory of components and their versions, down to transitive dependencies. Checking their state, through software composition analysis (SCA), which matches the dependency tree against databases of known vulnerabilities. Reducing the surface, by favouring official sources and signed packages, and removing what serves no purpose. Nothing paralysing here: tooled hygiene, built into the workflow rather than relegated to an end-of-line check.

The build pipeline: governing what runs

The continuous integration pipeline (CI, the automated chain that compiles, tests and assembles the software) is the moment code becomes a runnable artefact. It is also the least watched of the three fronts.

A pipeline often runs with broad privileges, handles secrets such as keys and access tokens, and executes third-party steps downloaded from outside. In an AI-assisted context, the agent sometimes touches the configuration of that chain itself. Each of these traits is a handhold for an attacker: compromising a single build step can be enough to insert code into everything the pipeline ships, without ever touching the source code that was reviewed. This is the point where keeping an AI-built prototype running in production becomes a craft distinct from getting it to work.

The ground is mapped. The Secure Software Development Framework published by NIST (the United States standards institute), the SSDF (publication SP 800-218), recommends building security in throughout the development cycle rather than relegating it to a final check. It insists on the integrity of components and their provenance, and treats the build environment itself as something to secure. Its logic is that of a management team, not a technical post: define practices, make them verifiable, hold them over time.

In practice, governing the pipeline comes down to applying the principle of least privilege, granting each step only the rights strictly needed, isolating secrets, controlling what runs and from which sources, and tracing the provenance of the artefacts produced. It is the highest-leverage front: barely visible, it underpins trust in everything else, because carefully reviewed code is worth nothing once it passes through an open factory.

Security as the condition for speed

The perimeter of application security has moved. As long as an application was written by hand by a contractor and run behind a guarded network, protecting the boundary made sense. Once the code is produced with AI, at a pace that outstrips review, the risk settles where the software is made: in the generated code, in the dependencies drawn in, in the pipeline that ships it all. Adding a network layer does not protect that surface.

Securing a business application built with AI then rests less on tooling than on a decision: treating the software factory as a surface to govern, with the seriousness once reserved for the network. A posture within reach of any organisation that chooses to make the risk explicit up front, rather than discovering it in production.

For the management team overseeing AI-assisted development, the final point fits in one sentence: make the risk measurable without taking back from the team the speed it has gained. Security here does not stand against the productivity of AI. It is the condition for that productivity to hold in production.