Staff are building AI workflows faster than oversight can keep up

An article published by The Hacker News on 20 October 2026 sets out a problem it calls "wild code": software, agents and automations that employees build with AI assistance faster than their organisation's existing processes can support them.

The piece opens with a worked example rather than a reported incident. A sales manager builds an AI-assisted workflow to route leads. According to the article, that workflow connects to customer records, summarises inbound requests and posts updates to a shared channel. It saves time, cuts manual work, and quickly becomes part of the team's daily routine. The article says that across the same organisation, employees are building useful apps, agents and automations at a pace that outstrips the processes meant to support them.

The security relevance is visible in the example itself. The workflow described is not a toy. It reaches into a system of record holding customer data, it processes text arriving from outside the organisation, and it writes output into a channel that colleagues read and act on. Each of those three properties — data access, untrusted input, and an audience that trusts the output — is something a security team would normally want to know about before the system goes live. In the scenario as described, nobody in a security function necessarily knows the workflow exists.

That is the core of the governance gap the article points to. Traditional application security assumes a development team, a repository, a review step and a release process. An AI-assisted automation built by a sales manager may have none of those. It is not shipped; it simply starts running. Inventory, the first step in almost any security programme, becomes the hard part.

It is worth being clear about what this article is and is not. It is a commentary piece, not an incident report. No breach, no compromised customer data and no named victim organisation are described in the material reviewed. The sales manager scenario is illustrative. Readers should not take it as evidence that a specific failure has occurred.

What the framing does usefully capture is a shift in who writes software that touches production data. When the tooling to build an integration drops to the level of a prompt, the population of people who can create one expands well beyond engineering. The controls built for the smaller population do not automatically scale to the larger one.

For security teams, the practical questions that follow are discovery and classification: what has been built, what systems does it touch, and which of those automations handle data or content from outside the organisation. The article's contribution is naming the category. The harder work of counting it remains with the teams on the ground.