A security questionnaire asks whether the vendor redacts sensitive data before it reaches a model. Almost every vendor can answer yes, and the answer is close to meaningless, because redaction matches field names and the riskiest field in a bug report has no names in it at all.
The questionnaire asks whether you redact, and that is the wrong question
The reviewer filling that row is usually somebody who already promised their team an AI feature on the intake path. The promise was cheap: pointing a model at bug triage is a prompt and an afternoon. The questionnaire is what turns it into a decision, and it arrives with a vocabulary that was built for a different problem.
“Redacted before transmission” was written for structured payloads, where every value arrives attached to a name and a name is something a rule can match. Our own capture path does exactly that, over the identity and metadata a host page attaches to a report and over the console and network snapshot travelling with it, using a fixed pattern of key names that a project can add its own keywords to and cannot remove any from.
The api-key term in that pattern covers three spellings rather than one, which is the detail that gets lost when somebody copies the list into an answer. The keys are authorization, cookie, password, token, secret, assertion, and apikey in its run-together, hyphenated and underscored forms, none of them a spelling with a space in it. Matching is case-insensitive and runs against any part of a key name, so X-Api-Key is redacted and a value that merely mentions one of those words is not.
That rule is sound and it is also narrow. It runs on the parts of a report a machine assembled, which is most of what evidence capture puts on a ticket, and a bug report is mostly the part a person wrote.
Redaction matches names, and a sentence has none
Take one report apart and the asymmetry is immediate.
| Part of a report | How it is bounded | What a rule can inspect |
|---|---|---|
| Identity and metadata the host page attaches | Keys matched against a fixed pattern, plus the project’s own keywords | The value, because the key names it |
| The console and network snapshot | The same key matching, applied to the entries themselves | The whole structure, because it is enumerable |
| The title | Derived from the comment’s first line when none is given, cut at 80 characters | Its length |
| The comment | Accepted up to 10,000 characters, handed to a model at 2,048 | Its length |
The finding is on the right. Two of those rows can be reasoned about by a reviewer who never sees a single report, because the rule is the same for every one of them. The other two can only be reasoned about by length, since there is no key to match against a sentence and no way to know in advance what somebody chose to type into it.
This is why the honest answer to the questionnaire is longer than yes. The structured half of a report is governed by a rule. The typed half is governed by a ceiling, and by whatever the form asked the person to write.
A character ceiling answers two questions at once
The ceiling is the number worth writing down, and it is the one a questionnaire has no row for. These are ours, read out of the shipping intake path rather than from a policy document.
| Stage | The declared ceiling |
|---|---|
| Comment the widget will accept | 10,000 characters |
| Title, when the reporter supplies none | the comment’s first line, cut at 80 characters |
| The text the enrichment call carries | the title, and the comment’s first 2,048 characters |
| Below which no call is made at all | 10 letters and digits, counted across title and comment together |
The last row is a cost control rather than a privacy one: a few characters carry nothing a model can classify, so the shortest reports never leave at all. The third row is the one a reviewer should copy into their answer. A reporter who writes a careful four thousand character account of a failure is read by the model to roughly the halfway point, and the ticket carries no marker saying that the second half was never seen.
That one ceiling answers two different people. It is the upper bound on what a single report can expose, which is what the questionnaire wanted. It is also the upper bound on what a suggestion was drawn from: a suggested title is written from the ticket’s title plus the comment’s first 2,048 characters, and from nothing after them. Each suggestion carries the model’s own confidence beside it, and one below the project’s threshold, 0.55 unless a project moves it, is stored and marked rather than offered as something to apply.
The field list is the part a reviewer can actually check
If the typed half cannot be inspected, the checkable property is the set of fields that cross at all, and the order in which a request can be refused before it is made. Ours refuses in five places before the first call, and re-reads three of them when the job actually runs.
| The refusal | What it stops | Where it is checked |
|---|---|---|
| The plan | Everything, on a tier without the feature | Before the project’s settings are even read |
| The project switch, which defaults off | Everything, until a project admin turns it on | At planning, and again when the job runs |
| The content floor | Text with nothing in it worth reading | At planning, and again when the job runs |
| The per-feature toggles | The half of the call nobody asked for | At planning, and again when the job runs |
| The monthly quota | Work past the project’s own ceiling | At planning |
The quota row is the ordinary one. The right-hand column of the switch row is what a reviewer should be asking about, because a switch read only at the moment a job is queued means a project turned off on Tuesday can still have Monday’s backlog sent on Wednesday. Re-reading the setting when the job runs costs one query and closes that window.
None of this is a claim about what a model does with the text. It is a claim about what a reviewer can verify without trusting anybody, which is a shorter list than most questionnaires assume: a closed set of fields, a ceiling on each, a role that can flip the switch, and the moment the switch is read. Those four belong on a security page rather than in an answer somebody has to request.
The decision belongs where the text is collected
The rule that generalizes past our own intake path is that a free-text field is an unfiltered channel by construction. No redactor reaches it, no data-processing agreement inspects it, and a policy that governs how a provider may use text says nothing about what the text contains. The only controls that act on it sit at the point of collection: what the form asks for, what the label above the box tells somebody to leave out, and how much of it the receiving path will carry.
So the useful version of that questionnaire row is two questions instead of one. Which fields cross, as a closed list. And how many characters of each, as a number the vendor will write down.
Two things are worth knowing before anybody turns this on. The widget tells the reporter nothing about any of this. Whoever runs the site is the one who decides what their own privacy notice says, which is why the switch defaults off and why it takes a project admin to move it. And similarity-based duplicate detection is not part of what runs today, whatever its toggle suggests: that path needs a second provider the service does not use, so no report’s text is sent for it.
