PyRIT is wired to a support assistant's chat endpoint and the run is clean. Which other intake paths of that application would you wire as separate prompt targets before calling the surface covered, and what does wiring each one require?

### The enumeration method Do not enumerate the ways a human types; enumerate the ways bytes end up inside the model's context window. Take the deployment's route manifest and its data-flow records, and mark every path where untrusted or semi-trusted content reaches a model context. That marked set is the target backlog, and it is almost always several times larger than the set of screens the product exposes. Three families fall out of it, and they differ in how hard the target is to build, not in how much they matter. **Synchronous, same shape.** Other request/response endpoints: a second locale or region, an older API version still routed for legacy clients, an internal or admin route, a partner integration, a second tenant. These are cheap — a new PyRIT prompt target with a different base URL, headers and credentials. The subtle variable is authorisation class. An admin route reached with an admin token behaves differently from the same route reached by the service identity that really calls it, and a target credentialed with the red teamer's own broad operator token measures a system no production caller inhabits. Credential the target as the **caller class that actually uses the path**. **Asynchronous, split shape.** Document and ticket ingestion, file and attachment upload, nightly batch summarisation, webhook and inbound-mail consumers. Here the framework's default assumption breaks. A prompt target's contract is send-a-prompt, get-a-response-to-score; on these paths the content is deposited through one channel and its effect surfaces later, in a different conversation, possibly for a different user. The target you write must therefore submit on the intake side and then poll or query a read side for the artefact the model produced, carrying a **correlation identifier** so a specific attempt can be matched to a specific effect, and a **bounded wait** so a slow pipeline registers as a timeout rather than a silent non-hit. Without correlation, concurrent attempts interleave and the scorer grades the wrong artefact — which produces confident, wrong results rather than obviously broken ones. **Non-text intake.** Voice transcripts, text extracted from images or scanned documents, structured form fields concatenated into a prompt template. By the time content reaches the model it is text, but your target has to speak the original format — produce the audio, the file, the field payload. That format work is usually why the path is skipped, and skipping it is invisible in the report. ### What each costs A synchronous target is an hour or two: URL, credentials, a smoke check. An asynchronous target is days, because you are building correlation, a read-back query and wait semantics against someone else's pipeline, and you often need a tenant or account that can absorb test traffic without touching real customers or real data. At run time the asymmetry continues: async paths have latency measured in minutes, which caps the turn budget far below what the chat endpoint tolerates, so a multi-turn strategy that is routine on chat may be affordable only as a handful of single-shot probes on ingestion. And every additional wired target multiplies metered calls per attempt — the target call, the scorer call, and the adversarial model call on each turn. ### Where the number misleads A clean chat-endpoint run gets reported as "the assistant is clean", and the phrase quietly generalises from one send path to the product. The generalisation is exactly backwards for risk: the chat endpoint is the surface a user consciously types into and the one most likely to have a guard in front of it, while ingestion and upload paths carry content nobody reviewed and often sit behind fewer controls. So the cheapest surface to wire is usually the best defended, and the aggregate rate is dominated by it. Worse, a partially built async target that silently returns nothing looks in the summary exactly like a path that held. Prioritise by two axes — how untrusted the content on the path is, and how privileged the model's downstream actions are once that content is in context — and then state plainly, next to the result, which paths were wired and which were not. Surfaces where the model calls out to tools have their own harness problem and belong to the agent-harness lane, not to a chat-shaped prompt target; the honest move is to name them as out of scope rather than let their absence read as a pass.