Triage wants an owner and a fix date for a jailbreak in a supplier's hosted model - what do you commit to?

**The remediation process assumes every finding has a fix, an owner and a date. Half the entries on an LLM list break that assumption, and the leadership skill here is refusing to pretend otherwise while still giving the organisation something to act on.** ### Why the pressure to give a date is real A tracker with an open item and no date looks like neglect. Reviewers, auditors and executives all read a blank date field as 'nobody is working on it'. So the path of least resistance is to write 'next release' and move on. In a tool-less consumer chat product built on a supplier's hosted model, that sentence is false in a specific way: your next release contains the system prompt, the client and the surfaces. It does not contain the weights that decide whether a request is declined. You have committed your organisation to an outcome no build of yours can produce. ### What an honest entry contains **One finding, two attributions.** Say which artefact each half lives in. The app half - prompt text, surfaces, session handling, what the product does with returned output - is in a repository your team controls. The model half is trained behaviour in a supplier-served endpoint. **A date only where there is a build.** The app-half work gets a named owner and a real date, like any other ticket. **A claim stated in what it shifts.** Whatever you ship on your side is described by its measured effect - how often the framing landed before and after, on which surfaces - not as closure. Any wording that implies removal will be quoted back at you the first time somebody reproduces it. **An explicit unresolved marker for the model half**, carried in whatever your organisation uses for risk it has not eliminated, with the reason stated plainly: no artefact under our control produces this behaviour, so no release of ours removes it. **The options that do exist**, named as what they are - decisions with owners above the engineering line. Narrowing who can reach the surface. Changing what the product does with the text it gets back. Changing which model the product calls, with everything that costs. Or continuing with the exposure known and stated. Presenting these as choices is the difference between a security function that informs decisions and one that files impossible tickets. ### The half-truths to reject *'We will fix it in the next release.'* The next release does not contain the model. This is the answer the interviewer is listening for you to avoid. *'It is the supplier's problem, so mark it closed.'* Location is not exposure. The output reached your customer under your product's name. *'We tightened the prompt, so it is resolved.'* A prompt edit moves a rate for wordings you tested. Ship it, measure it, and say so - but a resolved status asserts something you cannot demonstrate. *'It only reproduced once, so there is nothing to schedule.'* One success against a sampled model is exactly the evidence this class of defect produces. Reporting it as unreliable is honest; treating unreliable as absent is not. ### The organisational cost of the easy answer Dates are a currency. A team that promises one it cannot meet spends credibility it will need for the finding that genuinely does have a fix. Worse, the false date hides a decision from the people entitled to make it: if a product ships on a model whose behaviour it cannot control, that is a fact the product owner should hold consciously, not one buried under a ticket that closed on schedule and changed nothing that matters. The security function's job in that room is to make the residual visible and legible, not to make the tracker look tidy. ### What good sounds like in the interview A strong answer refuses the false date without refusing the responsibility. It gives the app half an owner and a date; it names the model half as unresolved with a stated reason; it describes the compensating work by its measured effect; and it escalates the remaining choice to whoever owns the product, because 'accept this, narrow it, or move off the model' is not a call an engineer makes in a ticket comment.