Applied AI
Security by Design for Generative AI Applications
July 2026 · 4 min read
A security-by-design checklist written for a conventional web application covers familiar ground: authenticate the user, authorize the action, validate the input, encrypt what is sensitive. A generative AI application needs all of that and then a second layer the checklist was never written for, because the application now has to reason about content it did not write and outputs it cannot fully predict.
I worked through this while building an AI image-generation product aimed at users in Indonesia — every image a person uploaded to generate a design concept had to be handled with the same care as any other sensitive user data, and every generated result had to be treated as something the system produced, not something it could vouch for unconditionally. Neither of those instincts comes for free; they have to be designed in.
This article lays out the security considerations I have found genuinely specific to generative AI features, beyond the baseline every web application already needs.
User-submitted content is untrusted twice
A conventional upload only has to be validated as a file: is it the type it claims to be, is it a safe size, does it contain anything malicious. A generative AI feature adds a second layer of scrutiny, because the same file also becomes model input, and model input can be adversarial in ways a file scanner will never catch — an image or a piece of text engineered to manipulate what the model does with it. Treating a user upload as safe once it passes a conventional file check is the mistake I have seen cost the most: the file check and the model-input check are different problems, and skipping the second because the first passed is how a generative feature ends up doing something nobody intended.
Do not trust generated output the way you trust a database record
It is tempting to treat a model’s output as a finished artifact once it is produced — store it, display it, pass it downstream — the same way an application trusts a value it read from its own database. A generated output deserves none of that trust by default. It should be validated against the constraints the feature actually needs — is this a plausible result, does it stay within the boundaries the product promised — before it reaches storage or a user, and it should be treated as untrusted content if it is ever rendered back into an interface, with the same caution given to any other unverified user-facing content.
Decide, explicitly, what a prompt is allowed to influence
A well-designed feature gives a user a narrow, well-understood way to influence a model — a description, a style choice, an uploaded reference image. It does not give the user’s input a path to influence the system beyond that: which internal instructions the model follows, what data outside the current request it can draw on, what it is permitted to do next. Every generative feature should be able to answer plainly what part of the system a user’s input can touch, and everything outside that boundary should behave as if the input did not exist.
Keep a human in the loop where the consequence is real
A guardrail I have come to rely on, learned first in an applied-AI product and later in a much more consequence-heavy compliance context: the model proposes, and where a decision genuinely matters, a human still disposes. In a consumer image product that might mean a clear boundary that generated output is inspiration, not a professional recommendation, communicated honestly rather than implied away. In a higher-stakes setting it might mean specific categories of judgment a model is never allowed to finalize on its own.
The design question worth asking of every generative feature is the same either way: if the model is confidently wrong here, what stands between that output and a consequence a user or the organization has to live with? If the answer is nothing, the feature is not finished.
None of this treats generative AI as uniquely dangerous — it treats it as a feature whose inputs and outputs are less predictable than the rest of the application, and designs accordingly. Security by design for generative AI is mostly the same discipline engineers already apply everywhere else, aimed at the two places a checklist written before these features existed forgets to look: what the model consumes, and what it hands back.