A client asks you to red-team an assistant whose tools can send email, file tickets and call a partner company's API on a user's behalf. How do you scope what the assistant may actually do during the test, and what goes in writing?

## Why an agent breaks the usual scope form A conventional scope document lists hosts: attack these addresses, not those. An assistant with tools cannot be scoped that way, because the thing you are attacking is not the address — it is a **decision loop**: 1. The model receives a prompt, 2. chooses a *tool call* (a named function with arguments, emitted as structured output), 3. the application's dispatch layer executes it against some real system with some real credential, 4. and the result is appended to the context so the model can choose again. The **reachable set** is therefore the transitive closure of everything those credentials can do, iterated over as many turns as the loop allows. An indirect injection that lands in a retrieved document does not respect the boundary you drew on paper; it respects the boundary the credentials draw. ## Build the inventory before you attack anything For each registered tool record: - the tool name as the model sees it; - the identity and credential the dispatch layer uses to execute it; - the scopes on that credential; - the systems it can reach; - whether the effect is reversible; - and whether anyone outside the engagement notices when it fires. That table *is* the scope. If the client cannot produce it, stop — that gap is a finding in its own right, and a serious one, because it means nobody in the organisation knows what their assistant can do. ## Tiering, and what a stub actually proves Settle each tool into one of three tiers. - **Reversible and internal:** run live. - **Irreversible but internal** — deleting records, rotating a credential — run live only against seeded test data with a restore plan agreed first. - **Anything that touches an estate the client does not own** — a partner's API, an outbound mail relay to real addresses, a payments or ticketing SaaS — defaults to a sandbox tenant obtained from that third party, or to a *recording stub*: an interceptor at the dispatch layer that logs the tool name and the arguments the model was persuaded to pass, returns a canned result, and never contacts the real system. The stub's evidence is precise and worth stating precisely: "the model was induced to invoke the transfer tool with attacker-chosen arguments." That is the vulnerability. Executing the side effect adds no information about it and adds legal exposure inside somebody else's system. ## Where this misleads, in both directions - A stub that returns a **canned success** can manufacture a chain that could not happen. The model, told the transfer succeeded, proceeds to the next step on data that would never have existed, and your transcript shows a five-step compromise of which only step one was real. - Conversely, **"tool invoked" is not "attack succeeded"**: the real tool sits behind its own authorisation, and a call the model was tricked into emitting may be rejected by the downstream service for a reason that has nothing to do with the model. Both errors have the same root — the stub replaces the part of the system that decides consequences. So report the invocation as the finding, and report the downstream authorisation state as a separate, verified fact, never as an inference. A count of "successful tool abuses" that mixes the two is a number nobody can act on. ## What it costs Building the inventory is a day with an engineer who knows the deployment, and it is the **highest-value day** in the engagement. A sandbox tenant from a partner has procurement lead time measured in weeks, so raise it at scoping or you will not have it. Stubbing is cheap to implement and cheap to run. The cost of getting it wrong is not billed in tokens: it is a partner's ticket queue full of adversarial test items, a real customer whose data an injection touched, and a relationship the client owns and you damaged. ## Test-only identities and stop conditions Dedicated mailboxes, a dedicated tenant, an allow-list on the outbound relay, and credentials scoped down for the engagement. Never run as a real customer's account: consent from the client is not consent from that customer. Agree in advance what halts the test: - an action lands in a real third-party system, - real customer data appears in output, - or the assistant does something irreversible you did not predict — and name a person on each side who can be reached within a stated time. Agree, too, who cleans up the artefacts the assistant creates. ## What you check when scoping is done Re-read the **credential scopes**, not the tool descriptions. A description says what a tool is *for*; a scope says what it *can do*. The gap between those two sentences is where the engagement's real risk lives.