Why doesn't validating a calendar invite's description field stop an assistant from obeying text an outsider wrote there?
answer
- two consumers, one old check
- shape, not meaning
- the check was sized for a renderer
- the renderer could not act; the model can
- nobody re-derived the trust call
basics
~20 sThe validator checked the field's shape for a screen that only displayed it: length, character set, encoding. Prose passes all of that unchanged, and the assistant now downstream of the same bytes reads prose as something to act on.
solid answer
~50 sValidation is always validation *for a consumer*. The invite description was checked years ago for a calendar renderer: a length cap, an allowed character set, maybe some markup stripped so the layout would not break. Those are checks on shape, and they were the right checks, because the worst a sentence in the imperative could do to a display page was be displayed. Adding an email, calendar and contacts assistant put a second consumer downstream of the identical bytes -- one that drafts replies, edits events and rewrites contact records. The consumer changed; the validation did not, because it lives on a write path that predates the assistant and belongs to another team. So "we validate that field" is true and beside the point: it proves the value fit the field, not that it is safe for something that can act.
go deeper
Be ready to say what passing a validator actually proves: the value fit the field's shape rules. Recall that the same text is later read by something that can act, and that the check was never written for that reader.
An interviewer expects you to trace the field from an outsider's write, through a shape check, into storage, into prompt assembly, and to point at the stage where a trust decision would have had to be re-made -- and note that no such stage exists.
Show that you would look for the field's original consumer and its owner before arguing about the model at all, and that you can state the residual plainly: the check is correct for what it was written for and silent about what now reads it.
Own the framing that validation is a relation between a field and a consumer, not a property of the field. The organisational consequence is that changing a consumer is a change nobody's process reviews, and that gap crosses two teams.
## The field has two consumers now An email, calendar and contacts assistant reads the owner's diary so it can answer "what is this meeting", draft a reply, or resolve who an attendee is against the address book. To do that, event text -- title, description, location, agenda -- is placed into the model's context. Not all of that text came from the owner. A calendar that accepts meeting requests from outside organisers writes the event, together with whatever prose the organiser typed into its description and location fields, onto the owner's calendar. That write is ordinary. It is what the invite feature is *for*, and no account was compromised to perform it. ## What the validator was written for The description field has been validated for years. When the validator was written, the field had exactly one consumer: a renderer that laid the text out on a screen. A renderer needs the text to be within a length budget, in a character set it can display, and free of markup that would break the layout. Those are the checks that exist. They were never checks on *meaning*, because meaning could not hurt a renderer. So passing validation proves one thing precisely: the value satisfied the predicate the validator encodes. That predicate is about shape -- size, encoding, permitted characters, sometimes a stripped markup subset. Ordinary prose survives every one of them, because prose was never what they were aimed at. ## Why nothing caught the change Three separate facts combine, and none of them is a bug in isolation: 1. **The write path is older than the assistant** and is owned by whoever maintains calendaring, not by whoever shipped the assistant. 2. **Validation happens at write time, for the consumer that existed then.** Nothing about the stored value records what it was validated *against*. 3. **No stage re-derives the trust decision when a new consumer is attached.** Attaching a model downstream is a change in who reads the bytes, and there is no step in anyone's process that asks whether a check written for a passive reader is still the right check for an active one. That third point is the whole of this topic. The defect is not in the validator and not in the model; it is that the question "what is this field trusted for, and by whom?" was answered once and never re-asked. ## Stage by stage | stage | what it sees | what it can decide about meaning | |---|---|---| | invite ingestion | the organiser's raw fields | nothing -- it checks shape | | storage | a stored string, no record of what it was validated for | nothing | | calendar renderer | the text | irrelevant -- it cannot act | | prompt assembly | the same text as context | nothing, unless someone built a stage for it | | the assistant | prose indistinguishable in kind from its own task text | it weighs, it does not enforce | ## What the attacker needs, and what they do not They do not need a bypass, a credential, or a flaw in the validator. They need a field they may already write into by design, which reaches the model's context substantially intact, in front of an assistant whose reach is the owner's reach -- because it acts on the owner's account. The cost is one meeting request. The write leaves the trace of a normal external interaction, because it *is* one. ## The weak answer, and the correction The reflex answer in an interview is "we validate user input." It is the single most common wrong answer here, and it fails on two counts. First, this is not user input in the sense the phrase means -- it was written by an outsider and arrives through a feature designed to let outsiders write it. Second, and more important, validation is not a property a field has; it is a relation between a field and a consumer. The description was validated *as calendar text for a renderer*. Nobody validated it as *instructions for something that can send mail and edit records*, because at the time nothing downstream could do either. ## Saying it precisely "That field is validated" is a statement about a predicate. It is not a trust boundary, it does not travel with the value, and it silently expires the moment something new starts reading the field. A candidate who can state that -- and then say who would have had to notice, and that nobody owns noticing -- has answered the question. A candidate who says "the model should just ignore instructions in data" has answered a different one, and has assumed away the property that made the field eligible in the first place.
- The team points out the description is capped at two thousand characters. Does the cap help?It bounds how much text arrives, not whether the text is directive. A cap constrains volume; the property that matters downstream is that a short, ordinary sentence reads as something to act on. If anything a cap pushes the writer toward concision rather than away from the field. It is a renderer's budget doing exactly its job, which is the point: it was never sized against this consumer.
- Does it change your assessment if the invite came from an authenticated external organiser?Authentication tells you who wrote the text, not that acting on it is safe. In this class the write is legitimate by design -- that is precisely why the carrier is attractive: no credential to steal, no anomaly to detect, and an audit trail that looks like a normal external meeting request. Identity is useful afterwards, for attribution; it does not change what the field is trusted for.
- Why wouldn't a code review of the assistant have caught this?Because the eligible field is not in the assistant's repository. A reviewer of the assistant sees a prompt-assembly step reading calendar text that has been validated on another team's write path for a decade, and there is nothing locally wrong with reading it. The change of consumer is invisible in both diffs -- it exists only in the relation between them.
A mail slot was cut to a size, and letters were checked only for fitting through it. That was enough while the person inside just pinned them to a board -- and stopped being enough when a new resident started doing what they said.
saying these in an interview costs you the question
- Says the field is safe because it is validated
- Treats a character-set check as a check on meaning
- Assumes an outsider cannot write to the owner's calendar
- Thinks stripping markup removes the sentence
- Calls it user input, so the user's own problem