In garak, what is a generator, and what do you have to own yourself when you wire one to a deployed chat application's authenticated HTTP endpoint instead of to a model you run locally?

### Where the generator sits in garak garak runs a scan as four replaceable plugin roles. A **probe** emits prompt strings. A **generator** delivers each prompt to the system under test and hands back a list of reply strings. A **detector** inspects those strings and rules which ones count as a hit. The evaluator/report stage aggregates verdicts into per-probe rates and writes the run's JSONL log. The generator is the only role that touches the network, which is why every engagement against a real product begins by getting it right. You pick the class with `garak --model_type` (`huggingface`, `openai`, `rest`, ...) and name the specific target with `garak --model_name`. For a deployed application the relevant class is garak's REST generator, driven by a JSON config passed with `garak -G <config.json>` (`--generator_option_file`). ### What a deployed app forces you to own A locally hosted open-weights model is close to a pure function: text in, text out, no credential, no envelope, no quota. A deployed assistant is an HTTP service, and each of the following becomes configuration you write by hand: | Concern | Where it lives in garak's REST generator config | |---|---| | Endpoint and verb | `uri`, `method` | | Credentials and gateway demands | `headers` — bearer token or API key, tenant id, API version, user agent | | Request body | `req_template_json_object`, with the probe's prompt substituted at the `$INPUT` placeholder (and the key at `$KEY`) | | Reply extraction | `response_json`, `response_json_field` | | Transport behaviour | `request_timeout`, `ratelimit_codes` | The `$INPUT` substitution is the point people miss: the app almost never accepts a bare prompt string, so the probe's text has to be threaded into whatever body the app expects, and the assistant's message has to be dug back out of whatever envelope it returns. ### What it costs Two currencies. **Engineer time**: a first correct REST config for a real product — auth, tenant header, body template, reply path, throttle codes — is usually half a day of round-trips with whoever operates the endpoint, not a five-minute edit. **Requests**: every attempt is a billed completion against the account whose credential you pasted into `headers`. The volume is prompts across the selected probes multiplied by `garak --generations` (which defaults to 10 in most releases — set it explicitly rather than inherit it), and the endpoint's requests-per-minute quota, not your machine, sets the wall-clock. ### Where the number misleads A misconfigured generator does not crash the scan. It completes, renders a report, and prints rates. That is the whole trap: a wiring error becomes a number instead of an error. Three concrete readings go wrong. - **Scope.** Because the app's own system prompt, retrieval context and output filter sit between your HTTP call and the weights, a low failure count means *this deployment resisted these probes*, not *the model is safe*. The converse also bites: a hit may be produced by a retrieved document rather than by the model, so the report must name the endpoint scanned, not just the model vendor. - **Credential expiry.** If the bearer token dies at ninety minutes and the sweep runs four hours, the tail of the run is 401 bodies stored as replies. Detectors find no violation in them, the failure rate falls, and the run reads as a deployment getting safer over time. - **Retries.** If the generator silently retries throttled calls, requests and spend rise while the coverage denominator does not move at all. ### What you check before a real sweep Send one hand-written benign prompt through the configured generator and read the stored reply verbatim out of the run's JSONL log — not out of the summary. It must be exactly the string a human user would see in the product. Confirm the credential outlives the projected wall-clock or that the generator can refresh it. Decide, and write down, whether throttles and errors are retried or recorded. Confirm which environment the `uri` points at, that the tenant in `headers` is one you are authorised to touch, and that someone has agreed to own the spend and the logs the run will generate.