TL;DR: Almost everything stays the same: threat modeling, authentication, authorization in code, least privilege, input and output handling, supply chain, logging and incident response. Three things change. The model cannot separate instructions from data, so injection has no parameterised-query fix. Its behaviour is probabilistic, so controls that rely on it lower rates rather than enforce boundaries. And the model is an artifact with its own supply chain and data lifecycle, from training data to weights.
How to approach it
The interviewer is testing calibration. Open by saying most of application security transfers unchanged, then name the specific differences and show what each one does to your designs. Anchor the answer in one system, for example an assistant that reads email and can send it, so the differences stay concrete.
A strong answer
- 1
1 · Stays the same
Core application security
- Threat modelling, authn, authz in code, least privilege
- Input and output handling, supply chain, logging, IR
- 2
2 · Changes: one channel
Instructions and data mix
- No parameterised-query fix for injection
- 3
3 · Changes: probabilistic
Same input, different output
- Test with rates, not single runs
- 4
4 · Changes: new assets
Models, prompts, indexes, agents
- New supply chain and data stores
What stays the same. The method and most controls. You still draw data flows and trust boundaries, authenticate users, authorize every action in code on the server, scope credentials, validate and encode at boundaries, keep secrets out of clients, patch dependencies and log enough to investigate. An LLM feature that skips these fails in the ordinary ways: a chatbot that fetches orders by an ID the model supplies, without checking ownership, has an IDOR bug that has nothing to do with AI.
What changes.
| Difference | Why it matters | What it does to the design |
|---|---|---|
| Instructions and data share one channel | Text from any author in the context can steer the model; there is no escaping or parameterising to make data inert | Treat everything the model reads as potentially hostile; limit what a steered model can reach |
| Behaviour is probabilistic | The same input can pass a filter once and fail it later; no test proves "never" | Use deterministic controls for boundaries; use classifiers and prompts to lower rates |
| The model is an artifact with a data lifecycle | Weights can be stolen or tampered with; training data can be poisoned or memorised and cannot be deleted from weights | Verify model provenance; keep sensitive data out of training; protect weights as crown-jewel assets |
The first difference deserves the most time. SQL injection was solved structurally: a parameterised query fixes the query's shape before data is bound, so data cannot become code. Language models have no equivalent grammar to enforce. That is why prompt injection is a design constraint rather than a bug to patch, and why the strongest controls sit around the model: per-call authorization on tools, scoped tokens, allowlisted outbound channels, sandboxes, and human approval for irreversible actions.
Old bugs in new places. LLM features also recreate classic vulnerabilities through new paths: model output rendered as HTML becomes cross-site scripting, a browsing tool becomes server-side request forgery, and a retrieval index that ignores permissions becomes a data leak. OWASP calls the first improper output handling. The fixes are the classic ones applied at the new boundary.
What interviewers probe next
- "So is prompt injection just another injection bug?" Same root cause, different fix: the boundary between instructions and data cannot be enforced inside the model, so you bound the consequences instead.
- "Would a better model fix this?" Better instruction-following and training lower success rates, but no published model is immune, and you cannot prove a negative by testing; the design still has to assume compromise.
- "What would you change in your secure SDLC for AI features?" Threat-model each new context source and tool, add adversarial evaluation to release gates, and treat model and dataset changes like code changes.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A seasoned application security engineer asks what is really new about securing an LLM feature, and what transfers unchanged.
Start here
What stays the same?
Which classic controls still apply?
Almost everything: threat modelling, authentication, authorisation in code, least privilege, input and output handling, supply chain, logging and incident response.
Carry it forwardMost AppSec practice transfers directly.
Weak answerTreating AI security as a new field from scratch.
Constraint changes
What is the first real difference?
Is there an equivalent of prepared statements for prompts?
The model cannot separate instructions from data, so injection has no parameterised-query fix. Defence moves to containment: limiting what manipulated output can do.
Carry it forwardNo structural fix for prompt injection.
Weak answerExpecting a filter to solve injection.
Constraint changes
What is the second difference?
Does one passing test prove anything?
Behaviour is probabilistic: the same input can produce different outputs, so testing reports rates over many trials rather than pass or fail.
Carry it forwardMeasure model behaviour as rates.
Weak answerSingle-run security tests.
Constraint changes
What is the third difference?
Which assets did your threat model not have before?
New assets and supply chain: model weights, training data, prompts and retrieval indexes, which can be poisoned, stolen or leak data in ways traditional components do not.
Carry it forwardModels, data and indexes are new assets.
Weak answerIgnoring training data and weights.
Constraint changes
How should the engineer apply this?
Which controls hold even if injection succeeds?
Use existing practices, then design for injection as an assumption: least-privilege tools, authorisation in code, untrusted output handling, confirmation for consequential actions, and evaluations measured as rates.
Carry it forwardAssume injection and contain impact.
Weak answerRelying on the model to refuse.
Now defend it
How would you summarise the difference?
Most of security transfers unchanged; what is new is that instructions and data share one channel with no structural fix, behaviour must be measured statistically, and models, data and indexes are new assets with their own supply chain. Design so manipulated output cannot cause harm, and measure.
How it's scored
Weak: Says AI security is a new field needing new tools, or says it is ordinary AppSec, without naming what specifically differs.
Hire: Names the instruction/data problem and probabilistic behaviour, and keeps classic controls such as server-side authorization in the design.
Strong Hire: Separates deterministic from probabilistic controls explicitly, covers the model's supply chain and data lifecycle, and shows how old bug classes reappear through LLM output and tools.
Common mistakes
- Treating a system prompt instruction as an access control.
- Forgetting ordinary bugs (IDOR, XSS, SSRF) because the feature "is AI".
- Claiming a classifier "prevents" prompt injection.
- Ignoring the model provider as a data processor with its own retention and terms.