I Built My App With AI. What Security Do I Need?

What changes when software gets built faster?

Traditional development timelines tended to create natural pauses. Deciding on an architecture took a conversation. Getting something into production took planning. Adding a payment provider or a new data store involved enough friction that somebody usually asked why, and occasionally asked whether it was safe. Those pauses were incidental rather than designed, but they gave organisations opportunities to think about risk at roughly the pace the product was growing.

AI-assisted development compresses a lot of that, and the fastest end of it, often described as vibe coding, compresses it further still. It does not remove design decisions, code review or deployment choices, and many teams using these tools are deliberate about all three. What it changes is timing. A feature that would once have taken a fortnight and three conversations can now appear in an afternoon, complete with a new integration and a new place where data lives, and the moments that used to prompt a review simply do not arrive.

Does using AI change who is responsible for security?

No. AI changes how some software is produced. It does not remove the need for someone to understand and manage what is running in production. It is worth separating three things that often get discussed as if they were one.

Technical understanding

Someone needs enough understanding of how the system works to make sensible decisions about it. That is not the same as understanding every line. It means being able to describe how users are authenticated, where customer data is stored, what the product connects to, and what would happen if a particular credential were exposed.

Organisational ownership

Someone in the company needs to own security decisions and recognise when outside expertise is needed. In a small team that is usually a founder, and that is a perfectly workable arrangement provided the ownership is explicit rather than assumed.

Legal or regulatory responsibility

What applies to your company depends on jurisdiction, the contracts you have signed, the data you handle and the sector you operate in. That is a question for qualified advice about your specific circumstances rather than something an article can answer.

“I don’t understand all the code the AI generated” is useful information rather than something to be embarrassed about. If nobody in the company can explain how an important part of the product works, that tells you precisely where review is likely to be most valuable.

When has your prototype become a real product?

The useful test is consequence rather than a launch date, a revenue figure or a headcount. A tool three people use internally on synthetic data sits in a very different place from the same codebase once it holds a customer’s records. The signals below tend to indicate that the stakes have moved. They are prompts to reconsider the security of what you have built, not a list of things every product is required to have addressed.

• People other than the founders are using it
• Customer or commercially sensitive data is being stored
• Users have accounts, permissions or different levels of access
• The product is running in production infrastructure
• Third-party systems or APIs are connected to it
• Secrets or credentials are being managed somewhere
• Money or payment-related workflows are involved
• Employees, contractors or partners have access
• Customers have started asking security questions
• An enterprise prospect has asked for evidence, testing or documentation

Several of these arriving in a short space of time is usually the clearest indication that the product has outgrown the assumptions it was built under.

What should you look at first?

The areas below are where founders most often find a gap between what the product does and what anyone has deliberately decided about it. The aim here is awareness rather than instruction: knowing what to ask about, and being able to tell whether you can answer confidently.

Authentication and access

Who can sign in, and how? What can each type of user reach once they are in? If the product has administrative or privileged functions, are those appropriately separated from ordinary user access? Products that grow quickly often acquire roles and permissions incrementally, and the resulting picture is worth writing down and reviewing rather than reconstructing from memory.

Customer data

What information does the application actually collect, including anything captured incidentally through logs, analytics or support tooling? Where is it stored, and for how long? Which people and which systems can reach it? A common surprise here is not the primary database but the secondary places data ends up as it moves between services.

Secrets and credentials

API keys, database credentials, signing keys and service tokens are the things that grant access to everything else, which is why they deserve deliberate handling rather than whatever arrangement happened to work first. It is worth knowing what secrets exist, where each one lives, who can retrieve them and what would be involved in replacing one.

It is also worth checking where secrets may have ended up by accident. Three places are worth looking first: values committed into the source-code repository, including in the history of past commits even if they have since been removed from the current files; keys shipped in code that runs in the browser or mobile app, where anyone using the product can read them; and configuration or environment files that were never intended to be public but have been deployed, published or shared. If you find something exposed, replacing the credential matters as much as removing it, because the old value may already have been read.

Third-party services and integrations

Your security picture extends to what you depend on: libraries and packages, external APIs, model providers, hosting and data services, and anything with access to your accounts. Each connection involves data flowing somewhere and permissions granted to something. Keeping an accurate list of those connections, and what each one can do, is worth the effort it takes.

Cloud and deployment

Secure application code and a secure environment to run it in are related but separate questions. How the infrastructure is configured, what is exposed to the internet, how access to the cloud account itself is controlled and how changes reach production all sit outside the application code. Cloud security work addresses that side of the picture.

The application itself

Then there is the product itself: where its trust boundaries sit, how it decides what a given user is allowed to do, how it handles input and data, and how it behaves when something unexpected happens. That is the territory of application security, which looks at how software is designed and built rather than only at what an attack finds.

What does “getting it checked” actually mean?

Founders often arrive at this point having heard four or five terms used as though they were interchangeable. They are not, and the difference matters because they answer different questions and cost different amounts.

Application security support

Useful when what you need is expertise around the security of the application itself: how it is designed, how key parts are implemented, and what decisions are worth making differently. This suits situations where the underlying question is “is this built sensibly?” rather than “can someone break in today?”

Threat modelling

Useful when important design decisions are still open and you want to understand where meaningful threats may arise before committing to an approach. Threat modelling tends to be most valuable ahead of a significant build or rebuild rather than after one.

Penetration testing

Independent testing of a defined system or application, carried out to identify exploitable weaknesses at a point in time. It produces evidence about a specific scope on a specific date, which is part of why customers sometimes ask for it. Our penetration testing page covers what the work involves and how scope is agreed.

Vulnerability assessment

A broader assessment intended to identify and prioritise vulnerabilities across a system or estate. It answers a different question from a penetration test and should not be presented, internally or to a customer, as the same thing.

Which of these is appropriate depends on the product, what it does, what is at stake if something goes wrong, and any requirements coming from customers or contracts. Not every application built with AI assistance needs a penetration test, and buying one because it is the term you have heard most often is a reasonably common way to spend money without answering your actual question. A short conversation with someone who does this work will usually establish which type of engagement fits.

What happens when customers start asking?

At some point a prospective customer raises security directly. They may ask about access controls, policies, testing, certifications, where data is held, or how you would handle an incident. What they ask for varies considerably depending on the customer, what they are buying and their own obligations, and there is no single list that all of them work from. Where the request arrives as a formal document, our guide to completing a security questionnaire walks through how to approach one.

This changes the nature of the conversation, because security is now attached to revenue and a timeline. The most common mistake at that stage is starting work on whatever was named in the email before establishing what is genuinely required. Our guide to what enterprise customers may ask startups for covers how those requests tend to be structured and how to work out which parts actually constrain the deal.

Common questions