Where does the application description you write for a promptfoo red-team run go by default, and what does that mean for what you are allowed to put in it?

### The default path `promptfoo redteam generate` does not, by default, write adversarial cases using a model you supply. It calls promptfoo's hosted generation service, and the payload of that call carries `redteam.purpose` — your description of the application — along with the plugin identifiers and strategies you enabled. The generated cases come back and are written into the local suite file. Everything after that (dispatching cases to the target, grading replies) runs from your machine, but the description has already left it. Nothing about this is a defect. It is how the tool produces strong, varied attacks without you standing up and maintaining a capable generator yourself. But it makes the answer to "can I paste our architecture notes in here?" *no, by default*, and it makes "has anyone reviewed this config for what it discloses?" a legitimate review question rather than a pedantic one. **Why the purpose is the sensitive string.** Every other field in the config is mechanical — an endpoint, a header name, a plugin id. The purpose is the one field whose value is a description of your business logic, your data, your roles and your internal policy, written by someone who was trying to be as specific as possible because specificity is what makes the attacks good. The incentive of the field pulls exactly against disclosure hygiene, which is why this trips people. ### Writing it so it can safely leave Describe classes and roles, not instances: - "reads the signed-in customer's own order records" rather than a pasted order. - "calls an internal refund service" rather than that service's hostname. - "three user tiers: anonymous, customer, agent" rather than a tenant or customer list. This is not only privacy hygiene. A pasted instance makes the generator overfit to that one example and produce near-duplicates of it; a described class produces cases spread across the class. The safe version is usually the higher-yield version. ### Turning generation local promptfoo documents an environment switch that disables remote red-team generation (`PROMPTFOO_DISABLE_REDTEAM_REMOTE_GENERATION=true`); cases are then produced through the generation provider you configure. State the consequences plainly: - Case quality and variety now track your local generator, which is usually the weaker model. - Some plugins and strategies are implemented on the hosted side. With remote generation off, those can yield fewer cases or none at all — read the per-plugin counts in the generate output instead of assuming you got the same suite in a different place. - Grading is a separate stage with its own provider, and the target itself is often a hosted API. Flipping one generation switch does not make the run offline, and claiming an air gap on the strength of it is a claim you have not checked. ### What it costs The money cost of the run barely moves; the costs are elsewhere. Locally generating a few hundred cases with a self-hosted model spends its tokens and its wall-clock, and on modest hardware that stage can dominate the run. The larger standing cost is that you now maintain two incomparable score series — anything generated hosted cannot be trended against anything generated locally. And the review cost is real and one-off: getting the default egress approved for one environment, once, is usually cheaper than permanently running a degraded generator. ### Where the number misleads Two readings go wrong. First, comparing a local-generation pass rate with an earlier hosted one as though the app improved: the generator changed, so the suite changed, so the denominator changed — the delta is an artefact. Second, reading a *smaller* generated case count as "fewer attacks were needed" rather than "coverage silently dropped for the plugins that only generate remotely". A missing plugin does not show up as a failure; it shows up as a harm class with no denominator at all, which reads on the report as nothing. ### What you would check Run one full `promptfoo redteam generate` followed by `promptfoo redteam eval` on a host whose outbound traffic you are logging — an egress proxy or firewall log — and read what actually left, from which stage. Diff per-plugin generated case counts between the two generation modes so a silently empty plugin is visible. Confirm the environment you ran in (laptop, shared CI runner, isolated evaluation host) is one where that egress is permitted. And put the purpose text under code review like any other config, because it is the artefact in the repository that discloses the most.