Flags

Open this before a portfolio-company meeting, not during a lesson. Each entry is one thing you might see, the question it turns into, the single role that can answer it, what a satisfactory answer sounds like, and the thing you are explicitly not claiming. That last column is the one that keeps you credible with people who do this for a living: an architect who states the limit of his own knowledge gets believed about the rest.

Two rules govern the whole page. One flag, one owner. If you have written two roles, you have two flags. No flag without a pass condition. A flag you cannot close is a flag you will raise again in three months, to a room that has started to tune you out.

The ceiling, restated

Exactly one flag on this page names you as the owner of the technical answer, and it is the one about your own component. Everything else ends with somebody else’s name on it. That is not under-confidence — it is the shape of the job. The architect who takes ownership of a control he cannot maintain has made the organisation worse, not safer.

The rendered surface

These are yours to notice and mostly not yours to fix. Every one of them starts with something you can observe in a browser in under five minutes.

Model output reaches an HTML sink

What you saw: A component renders model output as markup — raw HTML passthrough in a markdown renderer, dangerouslySetInnerHTML, or setHTMLUnsafe.
The question to ask: What sanitises this before it reaches the DOM, and where does that run — on every path, or only the one we tested?
Who owns the answer: Whoever owns the component. That is normally you, which makes this the one flag on this page you may also close.
What a satisfactory answer sounds like: A named sanitiser applied at the sink rather than at the source, with its configuration written down, plus the answer to what happens in Safari — where the native Element.setHTML() had no support at the time this page was written.
What you are not claiming: That you have found an exploit. You have found a sink and an untrusted source reaching it, which is a different and more defensible statement.

The browser fetches a URL the model chose

What you saw: A rendered image, link preview, iframe or favicon whose URL came from model output. Confirm it by watching the network panel, not by reading the renderer config.
The question to ask: Can conversation content end up in an outbound request that nobody clicked? And if we already restrict image hosts, what else is on that allow-list?
Who owns the answer: Shared: the component owner turns the rendering off, the platform or infrastructure owner sets and deploys the Content Security Policy. Name both, and say which half you are proposing to do.
What a satisfactory answer sounds like: Either auto-rendering is off by default, or img-src and connect-src are pinned to origins somebody can enumerate on request. A CSP that exists is not the answer; a CSP whose allow-list somebody can read out loud is.
What you are not claiming: That the allow-list is bypassable. You are asking what is on it, because two documented incidents were bypassed through entries that belonged to the vendor itself.

The exfiltration answer only covers images

What you saw: A team responds to the image question with “we disabled markdown images” and stops there.
The question to ask: What constrains the href of a link the model writes — which schemes, and which hosts?
Who owns the answer: The component owner. This is a renderer configuration question with a definite answer.
What a satisfactory answer sounds like: A stated scheme allow-list that excludes javascript: and data:, and a position on external hosts — even if that position is “any host, and here is why we accept it.” An explicit accepted risk closes a flag; an unexamined default does not.
What you are not claiming: That a click-through attack is likely. Only that a click is a hurdle the attacker gets to design, because the model writes the label.

The surface can initiate, not just display

What you saw: Something on the page causes a request, navigation, form submission or tool call from model-supplied content rather than from a user instruction.
The question to ask: Which elements here can start something, and what is the smallest set of them the feature actually needs?
Who owns the answer: The agent or platform owner for tool permissions; the product owner for whether the capability is needed at all. Not the same person, and the second one is usually the one who can actually remove it.
What a satisfactory answer sounds like: An enumerated list of what the surface can initiate, and a reason each one is present. The standard OWASP applies to tools and permissions is “the minimum necessary”, and that is a standard somebody can be held to.
What you are not claiming: That the capability is wrong. Capabilities are product decisions. You are asking for the list, which nobody has usually written down.

The confirmation shows a summary, not the action

What you saw: A human-in-the-loop approval screen renders a model-written description of what will happen, while the executor runs a payload the screen never showed.
The question to ask: Does the confirmation render from the same payload the executor will run?
Who owns the answer: Shared and worth naming precisely: the component owner for what the screen renders, the agent runtime owner for what gets executed. The flag is about the gap between them, so both need to be in the thread.
What a satisfactory answer sounds like: Two file paths and a demonstration that the displayed fields derive from the executed payload. Where a field is unreadable, showing the opaque value or a trusted lookup of it — never a friendly gloss the model wrote.
What you are not claiming: That the gate is useless. A gate with a fidelity gap still stops a lot. It just does not stop the thing it was bought to stop.

Somebody proposed filtering the injection away

What you saw: A plan to detect and strip injected instructions, usually with a second model, shipping once accuracy is “good enough”.
The question to ask: What happens when it misses one, and how would we know it had?
Who owns the answer: Application security, jointly with whoever proposed it. Raise it as a design question, not a correction — this proposal is made in good faith almost every time.
What a satisfactory answer sounds like: An acknowledgement that the filter reduces volume rather than closing the class, and a named architectural control that does not depend on detection working. OWASP’s 2026 position is that no reliable prevention mechanism exists and that defence has to be architectural rather than interceptive; agreement with that framing is the real pass condition.
What you are not claiming: That the filter is worthless or that you have a better one. You do not, and neither does anybody else.

Data in the UI

Nothing is being attacked in this group. Data leaves through instrumentation somebody added deliberately, which is why it survives security review and shows up in a privacy review instead.

A third-party recorder is running on a surface that shows personal data

What you saw: Session replay, analytics, a heatmap, or an error monitor loaded on a page that displays documents, extracted fields, transcripts or account data.
The question to ask: What does this tool mask by default, at the version we have installed — inputs only, or page text as well?
Who owns the answer: Whoever owns the telemetry stack. The privacy owner cares about the answer but usually cannot tell you what the SDK does.
What a satisfactory answer sounds like: A stated default, tied to a major version, checked against the vendor’s own current documentation rather than remembered. The defaults genuinely differ — some tools mask all text, at least one records everything except password inputs — and at least one vendor’s pages disagree with each other across SDK versions.
What you are not claiming: That data has leaked. That the default is unknown to the team is the finding, and it is enough.

The masking posture can change without anyone deciding

What you saw: A telemetry SDK major-version bump in a dependency update, on a surface that renders personal data.
The question to ask: Did the privacy defaults change in this major version, and did anyone check?
Who owns the answer: The telemetry stack owner. This is also the flag most likely to be closed by a five-minute reading of an upgrade guide, which makes it cheap to raise.
What a satisfactory answer sounds like: Either a confirmation that the default is unchanged, or an explicit configuration that pins the behaviour so the next upgrade cannot move it silently.
What you are not claiming: That the upgrade was careless. Masking defaults moving across major versions is documented behaviour, not an oversight by whoever ran the update.

A trace or debug view shows everything by construction

What you saw: An internal observability surface that renders every input and output of every step, including whatever the user uploaded.
The question to ask: Who can open this view, and is what it shows redacted at the source or only hidden in the UI?
Who owns the answer: Shared: the platform owner for what the trace store holds, the privacy owner for whether holding it is permitted. Access control is usually a third party again.
What a satisfactory answer sounds like: Redaction happening before storage, or an access boundary somebody can describe in terms of roles rather than of who currently has the link. “It is internal only” is not an answer; it is a description of the current audience.
What you are not claiming: That the view should not exist. It should. A trace view that hides the failing step is worthless, and that tension is real rather than something to resolve in a meeting.

Nobody has named a retention period for transcripts

What you saw: Agent conversations, uploaded documents or traces persisted with no stated expiry, usually because the feature shipped before anyone asked.
The question to ask: How long do we keep these, who decided that, and where is it written?
Who owns the answer: The privacy or data protection owner. Engineering can implement a period and cannot choose one.
What a satisfactory answer sounds like: A number, a document it lives in, and a named person who owns it. “Indefinitely, and that is a deliberate decision recorded here” is a satisfactory answer. “We have not thought about it” is the finding.
What you are not claiming: That the retention is unlawful. You are not qualified to say that and saying it will cost you the room.

Personal data is crossing a border nobody named

What you saw: An inference call, a document store or a telemetry endpoint in a region different from where the customer’s users are, or a processor whose region nobody can state.
The question to ask: Whose data is this, and which jurisdictions does it touch between the browser and storage?
Who owns the answer: The privacy or data protection owner, with legal. This is the flag where trying to answer it yourself does the most damage.
What a satisfactory answer sounds like: A named transfer basis for each hop — an adequacy decision, standard contractual clauses, or a derogation — rather than a claim that data stays in one place. The rule under Chapter V of the GDPR conditions transfers rather than forbidding them, so the answer is a mechanism, not a map.
What you are not claiming: Any view on whether the mechanism is sufficient. It is being contested in court and by regulators while you read this, and that is exactly why it is not your call.

Raising it properly

Not flags about a surface — flags about the flag. These are the questions that decide whether the other twelve get closed or quietly filed.

The telemetry vendor is inside somebody’s SOC 2 scope

What you saw: A new front-end analytics, replay or monitoring vendor added to a product whose customers ask for a SOC 2 report.
The question to ask: Is this vendor a subservice organisation for our report, and if it is carved out, does our report say anything about its controls?
Who owns the answer: The compliance owner — whoever the auditor talks to. Not security, and not you.
What a satisfactory answer sounds like: An answer that uses the actual vocabulary: whether the vendor performs controls the company’s own commitments depend on, and whether it is handled by the carve-out or the inclusive method. Under carve-out, its system components are excluded from the description and from the scope of the examination — which is a defensible choice and a fact worth knowing before a customer asks.
What you are not claiming: That adding the vendor breaks compliance. It probably does not. The flag is that a front-end decision moved something inside an audit boundary, and that the person who owns the boundary has not been told.

Somebody is treating a SOC 2 report as a security guarantee

What you saw: A vendor’s SOC 2 badge offered as the answer to a security question about that vendor.
The question to ask: Which criteria did that examination cover, over what period, and does it include the part we depend on?
Who owns the answer: The compliance owner, who can read the report. You are asking for the report to be read, not summarised.
What a satisfactory answer sounds like: Somebody says which trust services categories were in scope, whether it was a type 1 or a type 2, and what the period was. Type 2 adds operating effectiveness over a period; type 1 is design at a point in time. A badge alone answers none of that, and it licenses use for twelve months from the report date.
What you are not claiming: That the vendor is insecure. Only that a report about controls is not a statement about the specific risk you asked about.

The flag has more than one owner

What you saw: Your own flag log, with two roles in the owner column.
The question to ask: Which single role can close this, and what would the other one be doing?
Who owns the answer: You. This is a defect in the flag, not in the organisation, and it is the most common one.
What a satisfactory answer sounds like: One role in the column. If the work genuinely spans two, it is two flags with two pass conditions, each closable on its own.
What you are not claiming: Nothing. This one is entirely yours, which is why it is the only flag on this page you can fail at privately.

The flag has no pass condition

What you saw: A row where “what a satisfactory answer sounds like” is empty, or says something like “they confirm it is fine.”
The question to ask: What exact sentence, from what exact role, would let me mark this closed?
Who owns the answer: You, again.
What a satisfactory answer sounds like: A written sentence specific enough that you would recognise it if someone said it, and specific enough that you would notice if they said something adjacent instead. Vague pass conditions are how a flag gets re-raised for a year.
What you are not claiming: Nothing. But note that a flag you keep re-raising costs you more credibility than one you never raised.

The sentence that is never satisfactory

“We sanitise the prompt.” It describes a control class the current OWASP guidance records as insufficient, and saying it is the fastest way to stop being listened to by the person you most need. The reply that works is not a correction but a question: what happens when it misses one? A control with no answer to that is a hope with a budget.

The counterpart is worth writing down too. Prompt injection has no known general fix, so a flag that demands one will never close. Every pass condition on this page asks for a constraint, an enumeration, a named owner or an accepted risk — things an organisation can actually produce.

Every claim on these pages links to its source. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.