Disclosing to a Provider

## The four levers the customer actually holds An application built on a hosted model endpoint is a pipeline the customer owns everywhere except one box. Left to right, the owned parts are: **prompt assembly** — the system prompt, the templates, and everything the application concatenates around the user's text before it calls the API; **retrieved context** — whatever a retrieval step pastes in, which becomes attacker-influenced the moment any part of that corpus is user-writable; **tool and permission scope** — the set of functions the model is allowed to invoke and the credentials those functions execute under; and **input/output filtering** — a classifier, a regex, a moderation call, or a schema validator applied on the way in or on the way out. The one box the customer cannot change is the model plus the provider's internal safety stack: the weights, the alignment training, and whatever the provider applies before and after sampling on their side. Routing a finding means testing it against each owned layer before the word "provider" appears anywhere in the write-up. That is the whole discipline, and it is mostly not done. ## What the layer test costs A model finding is a *rate*, not an event, so testing a layer means re-running the same trial count against a modified pipeline. If the effect was established at 12 successes in 50 attempts, an honest check of four layers is four more 50-attempt runs — 200 attempts. Single-turn, that is ~200 API calls; if the effect needs a five- or six-turn build-up, the same 200 attempts is 1,000-1,200 calls, and doubles again if an automated judge scores each transcript. On a mid-tier hosted endpoint the money is rarely the constraint — often well under 50 US dollars. Two other costs bite: **wall clock**, because a 60-requests-per-minute quota turns 1,200 calls into a 20-minute serial run before retries and backoff; and **engineer time**, because each layer test needs a variant of the application stood up with exactly one thing changed. Budget the routing work as its own half-day of the engagement. Teams that do not budget it skip it, assume the provider owns the finding, and file upstream by default. ## Where the number misleads: the clean re-test The dangerous reading is "we added the output filter, re-ran the suite, got 0 of 50 — customer-side fix confirmed." Zero successes in n attempts does not bound the true rate at zero. The standard approximation (the rule of three) puts the top of a 95% interval for zero hits in n trials at about 3/n, so 0/50 is consistent with a real rate as high as roughly 6%. A control that took a 24% rate down to 4% will show zero hits in a 50-attempt run reasonably often, and will usually show one or two, which a tired reader rounds off as noise. Two consequences follow. First, never write "removed" on the strength of a clean small run — write "not observed in 50 attempts; upper bound approximately 6%." Second, and larger: the suite is fixed and does not react, while an attacker does. A filter that cuts your prompt set's rate from 24% to 4% may cut an adaptive attacker's rate not at all, because the attacker rephrases against the filter's observed behaviour. Rate reduction against a fixed suite is evidence about the suite, not about an adversary. ## What changes when the provider is the owner Three properties of a provider-owned item make it a different document. There is **no date**, because you cannot set a remediation deadline for a party who is not in the engagement. There is **no guaranteed verdict**, because the provider may rule the behaviour intended, and their triage is not something you can appeal on the customer's behalf. And there is **no observable patch event**, because a hosted model can change silently with no version you can cite, so "resolved" is something you re-measure, not something you are told. So the item is written mitigation-first: the observed effect and its impact on this application; the evidence that no owned layer removes it; the compensating control the customer can deploy this week (narrow the tool scope, gate the sensitive action behind a human step, drop the capability, or filter the specific effect at the boundary); the residual risk left after that control, with its denominator stated; the upstream submission reference and status as a single line; and a re-test date. ## What to check before committing to "provider owns this" Did you actually build and test each layer variant, or infer it? Is the impact expressed on the customer's asset rather than on the model in the abstract? Is the customer's system prompt merely *asking* for a constraint it could enforce structurally — a very common false attribution upstream? And is the residual-risk number written with what it is a fraction of, so nobody reads "4% of crafted attempts" as "4% of traffic"?