Skip to content
AI-built software and security: the best case, the worst case, and how to land on the right side of that line
Back to blogSecurity

AI-built software and security: the best case, the worst case, and how to land on the right side of that line

6 min read

Every conversation about AI-assisted development eventually gets to security, and it should.

Three shapes this takes, in practice:

Good

A logistics company has an AI-assisted booking tool built for them. Before launch, someone reviews how customer data is stored and who can access what. Rate-limiting, route separation, dependency tracking: all in place. Six months in, a routine scan flags an outdated library; it's patched the same week, before it ever mattered.

Bad

A retail business has an AI tool build them a customer portal in a weekend. It works. Three months later, a routine audit finds customer order histories visible to any logged-in user, not just the account owner: a permissions check that was never added. Fixed in a day once found. But for three months, anyone with a free account could have browsed every customer's order history.

Worst

A startup ships an AI-generated backend for handling user-submitted files. The code trusts the structure of incoming data without properly validating it: a well-documented class of flaw. Someone outside the business finds it, months later. There's no way to know how long the door was open. "The AI wrote code that ran without errors" was never the same as "the AI wrote code that was safe."

Common failure classes behind that "worst" pattern, not exotic, just easy to miss when nobody's specifically looking:

  • Authentication logic that works for the tested path and fails open for anything else.
  • Input validation gaps: trusting data that shouldn't be trusted, including how a system deserializes structured input from outside sources.
  • Secrets or config left where they shouldn't be, because nobody was specifically responsible for checking.
  • Dependencies pulled in without anyone tracking what they are or whether they're current.

The gap between best case and worst case isn't the tool. It's whether a review step exists, and whether someone is accountable for it. That's built into how we deliver AI Development work: deliberate scoping, a review step before anything ships, and someone answerable for the decisions made along the way.

Fast doesn't have to mean unreviewed.

Want an experienced pair of eyes on an AI build before (or after) it goes live?

Reach out