The Half You Control

**Every finding has to answer one question before it can be scheduled: which artefact would have to change for this to stop happening?** On an LLM product that question splits the estate in two, and only one half has a version number. ### The shape of the product decides the answer Take a study-companion chat app on a phone. Its team writes a system prompt, the user types turns, and a hosted frontier model answers over an API behind a version label the vendor rotates. There is no retrieval, no tool, no memory outliving the session. The only text reaching the model that the team did not write is the paying customer's own message, and the only thing that can leave the system is text rendered back to that same customer. That shape removes one of the two things people usually mean by prompt injection. Injection aims at the *application's* own instructions, and it needs a path by which text somebody else wrote reaches the model as part of the application's data - a retrieved chunk, a fetched page, an inbound mail, a tool's return value. This product has no such path. What is left is the other target: the *model's* trained refusal, addressed by the user in their own turn. The published list files jailbreaking under its prompt-injection entry, so one entry spans both targets - and the ownership line runs straight through the middle of it. ### Split the estate | What it is | Who ships it | A version you can bump? | | --- | --- | --- | | The system prompt text | your team | yes | | The chat surface, session handling, client | your team | yes | | What the product does with the returned text | your team | yes | | Which model and which label you call | your team | yes - you can change supplier, not their behaviour | | The propensity to decline a request | the supplier | no | | How that propensity is sampled at generation time | the supplier | no | Everything above the line has a repository, a build and a release you can put a date on. Everything below it is trained behaviour in weights you did not produce, served from an endpoint you do not operate. Several entries on the LLM list sit squarely in the first group - how the application handles what the model returned, how much the application is allowed to do on the model's say-so, what the team put in the system prompt that later leaked. Those findings have an owner, a repository and a date. A framing getting past a trained refusal does not, at least not on your side of the line. ### What an app-side change actually buys Rewording the system prompt is a change in the half you control, and it can move the observed rate for the wordings that were tested. It does not alter the trained propensity, because the propensity is not stored in the prompt - the prompt is text the model reads, not a rule the runtime enforces. The same goes for narrowing which surfaces exist or which users reach them. The honest description of any such change is what it measurably shifts, never what it removes. Describing it as removal is how a team ends up telling a reviewer that a defect is closed while the same transcript is still reproducible. ### Why this matters more than it sounds The usual wrong answer is 'we will fix it in the next release'. Your next release ships the prompt, the surface and the client. It does not ship the weights. A date on somebody else's release train is a promise nobody in your organisation can keep, and the cost is not only this ticket: the next date your team gives is believed a little less. ### Getting the direction of the claims right One success proves the framing landed once, on one deployment, at one moment. A refusal on the next attempt proves that attempt was declined, not that the finding evaporated. And 'we cannot patch it' is not the same as 'it is not our problem': the transcript carries your product's name, the person who saw the output used your app, and the exposure is yours even when the behaviour is not.