You have a fixed spend for a PyRIT engagement. How do you divide it between many objectives at a short turn budget and few objectives explored deeply, and how do you report what the money bought?
answer
- breadth sweep to rank, depth on the top of the ranking
- failed objectives are the expensive ones
- cap per-objective spend
- reserve for reproduction and follow-up
- report objectives that hit the cap, not just a pass rate
basics
~20 sSplit the budget: a broad shallow pass to find which objectives show movement, then deep turn budgets spent only on those. Cap spend per objective so one runaway conversation cannot eat the pass. Report cost per objective and per confirmed finding, and state which objectives were cut short rather than cleared.
solid answer
~60 sTreat it as a two-stage allocation rather than one global setting. **Stage one — breadth.** Run the full objective set at a short turn budget. Cheap per objective, and its purpose is not to find breaches but to rank: which objectives produced partial compliance, hedging or escalating behaviour before the budget ran out. **Stage two — depth.** Spend the remaining budget on the top of that ranking with a long turn budget, because depth is where multi-turn attacks actually land. The hard constraints around it: per-objective spend is unpredictable — a loop stops early on success but runs to the ceiling on failure, so the *expensive* objectives are the unsuccessful ones. Cap spend per objective so a single conversation cannot consume the pass, and reserve a slice for re-running confirmed findings, since a finding you cannot reproduce is not reportable. **Reporting.** Two numbers matter: cost per confirmed finding, and the list of objectives that hit their cap. The second is the honest part — those are not clean results, they are unfinished ones, and a report that merges them into a pass rate overstates what the money bought.
go deeper
Should recognise that a fixed budget forces a choice between covering more objectives and running each one longer.
Proposes a staged breadth-then-depth split and a per-objective spend cap, and knows the turn budget is a ceiling rather than an expected cost.
Budgets from the worst case because failed objectives run to the ceiling, reserves for reproduction, and reports capped objectives separately from cleared ones.
Owns the reporting frame — cost per confirmed finding alongside attempts, capped objectives and the stage split — and manages the stakeholder reading where a low finding count is credited to the system rather than to the budget.
The tempting allocation is one turn budget applied to everything. It is the worst one available, because it spends exactly as much on an objective that will never move as on the one that would have broken on turn twelve — and it spends it on the wrong side of that pair. ### Terms An **objective** is one goal pursued in one conversation. The **turn budget** is PyRIT's `max_turns` on the attack: a ceiling on how many adversarial-target-scorer cycles that conversation may run before the loop gives up. Each turn bills three legs, so per-objective spend is roughly `max_turns` x 3 calls, and more once converters fan out or a second scorer is attached. The engagement's fixed spend has to be divided across objectives, and the only levers are how many objectives you attempt and how deep each is allowed to go. ### The staged allocation Run **stage one** as a short-`max_turns` sweep across the full objective set. Its purpose is not to clear anything — a short budget cannot, and the sibling failure mode is precisely that a too-short run reports refusal where a longer one would have found a breach. Its purpose is to **rank**: objectives that eventually break tend to show early signal — partial compliance, negotiation, a drift in the target's stance across two or three turns — and those are cheap to detect. Run **stage two** as long-`max_turns` runs against the top of that ranking, because multi-turn attacks land in depth, not breadth. Worked, to show why the split is affordable: 40 objectives at `max_turns` 5, one variant, one scorer is 5 x 3 = 15 calls each, 600 calls for total coverage. Promoting 8 of them to `max_turns` 30 is 90 calls each, 720 calls. Full breadth costs less than eight deep runs. ### Where that number misleads Call count is linear in turns; **spend is not**. The adversarial chat is conditioned on the whole transcript, so its input grows with turn number and its cumulative token cost over an objective grows roughly with the square of the turn count. A 30-turn objective therefore costs far more than six times a 5-turn one, even though it makes six times the calls. Any budget built from a per-turn average measured on the shallow sweep will under-forecast the deep stage badly. The second inversion is more important. The loop terminates on success or on the ceiling, so **the objectives that produce nothing are the expensive ones** and the ones that break on turn three are the cheapest. Ordinary intuition has this backwards. It means a pass with a low success rate costs close to its theoretical worst case, and a budget computed from average per-objective cost will be wrong in exactly the direction that hurts. Model the worst case — every objective at its cap — and treat any early termination as recovered budget for stage two. ### Reserves Two are non-negotiable. One for **reproduction**: a finding that does not reproduce is not reportable, and re-running a successful objective costs roughly what it cost the first time. One for **follow-up**: the useful output of stage two is usually an objective nobody wrote down at kickoff, and an engagement with no slack cannot chase it. Cap per-objective spend as well, so a single runaway conversation cannot consume the pass. ### What to report Cost per confirmed finding is the number leadership understands, and on its own it rewards the wrong behaviour: it looks best when you only run objectives you already knew would break, which is the opposite of discovery. Pair it with three others — objectives attempted, **objectives that terminated at their cap**, and the split of spend between the breadth and depth stages. The middle one is the honest part and the one most often missing. An objective that exhausted its turn budget without a hit is unfinished, not cleared; merging it into a pass rate manufactures a clean result out of an under-funded run. State it plainly, because whoever approves the spend will read a low finding count as good news about the system, when it is at least as likely to be news about the budget. That single line is what keeps the two readings distinguishable, and it is what lets the next engagement's budget be argued from evidence rather than from last time's total.
- Why are the unsuccessful objectives the expensive ones?Because a multi-turn loop terminates on success or on the turn ceiling. An objective that breaks on turn three bills three turns; one that never breaks bills the whole budget. A pass with a low success rate is a pass where nearly everything ran to its cap.
- What is wrong with cost-per-finding as a lone metric?It improves when you only run objectives you already expect to succeed, which is the opposite of discovery. Pair it with objectives attempted, objectives that terminated at their cap, and the breadth/depth split of spend.
- How much do you hold in reserve, and for what?Enough to re-run every confirmed finding once — reproduction costs about what the original run cost — plus a slice for objectives nobody wrote down at kickoff, which is where the depth stage usually points.
saying these in an interview costs you the question
- One global turn budget applied uniformly to every objective.
- Budgeting from average per-objective cost when most objectives will run to their ceiling.
- Reporting objectives that exhausted their budget as clean results.
- Optimising cost per finding by only running objectives already known to break.
- No reserve for reproducing a finding.