Scoping decides the test. Everything else just executes it.

The short version: most disappointing pentests were scoped to fail before anyone touched a keyboard. The two decisions that matter most are which identities the tester gets and which surfaces are named in bounds. Supply real accounts for every role and every tenant, name the web app, the API and the agent surface as distinct things, and write rules of engagement that make production safe to test. Do that and the authorization and business-logic bugs — the ones worth paying for — are reachable.

Why scope is the whole game

A scanner tests what it can see from the outside. A real test is bounded by what you authorise, and the highest-impact classes live behind that boundary: can one customer read another's invoice, can a support role reach an admin action, can a negative quantity survive checkout. None of those are visible to an unauthenticated crawler. They are only reachable if the scope hands the tester the keys to stand in each role and try. When people say a pentest "didn't find much," the cause is usually upstream of the testing — the scope never let it near the layer where the bugs were.

Identities and tenants: the part people underfund

Authorization is tested by replaying a request as someone it wasn't meant for. That is mechanically impossible without accounts. For every distinct role — anonymous, standard user, admin, support, billing — provide a working test account. For a multi-tenant product, provide at least two tenants, because cross-tenant data access (user A's organisation reaching user B's organisation's objects) is one of the most common and most damaging findings, and you need two sides to prove it. A test with one account is a test of the front door with the keys left at home.

Three surfaces, three different scopes

"The app" is usually three surfaces wearing one domain. Each needs to be named explicitly, because each is tested differently and each hides a different class of bug.

The web application is the surface most people mean. Scope the roles, the login and session mechanism, and any feature flags that change what a role can do. The API is often the same logic with the UI removed — and it frequently enforces less, which is why BOLA/IDOR and mass-assignment bugs cluster there. Hand over the OpenAPI spec or a Postman collection and tokens for each role; a test driving the API directly reaches endpoints the web client never calls. The AI agent is the newest and least-scoped surface: treat it as an identity with tools. The questions are whether untrusted content it reads can steer it (indirect prompt injection), whether its tool-call and permission boundaries hold, and whether its MCP or function surface over-permits. That is not a sub-feature of the web test; it is its own scope line.

Rules of engagement that make production safe

Scope says what; rules of engagement say how far. The point is to make even a production test safe and reversible: benign canaries instead of live payloads, a rate ceiling so load never becomes an outage, an explicit stop signal on either side, and named exclusions (no destructive actions, no social engineering of staff unless agreed, no third-party assets you don't own). Authorisation must be deterministic and written — a wildcard *.example.com authorises subdomains; a bare apex does not — and nothing should run until ownership of the target is confirmed. Good rules of engagement are what let you point a real test at the environment that actually matters without holding your breath.

The scoping checklist

If you can answer these, your test is scoped to find the expensive things:

• Surfaces named? Web app, API and any AI-agent surface each listed explicitly, with their hosts and base URLs.
• An account per role? Anonymous, user, admin, support, billing — whatever roles exist.
• At least two tenants? So cross-tenant access can be proven, not just suspected.
• API contract supplied? OpenAPI/Postman plus per-role tokens.
• Agent surface described? Its tools, permissions, inputs and MCP/function endpoints.
• Rules of engagement written? Allowed methods, rate ceiling, stop signal, exclusions.
• Authorisation confirmed? Ownership verified, scope signed by both sides.
• The right environment? Production or a production-faithful staging with real auth and data shapes.

FAQ

What information does a tester need to scope the work?

In-scope hosts, apps, APIs and agent endpoints; one test account per role and tenant; API specs or Postman collections; and rules of engagement (allowed methods, rate ceiling, stop signal, exclusions). The most valuable thing you can give is working credentials per role — the authorization layer can only be tested by replaying requests as different identities.

Should staging or production be in scope?

Test the environment whose behaviour you care about — usually production or a production-faithful staging with real authorization and data. A staging box with auth disabled hides exactly the access-control and logic bugs you're paying to find. If production is in scope, bound it with narrow budgets, benign canaries and a circuit-breaker.

How do I scope an AI agent or chatbot?

Treat the agent as an identity with tools. Scope the inputs it reads (including untrusted content), the tools and permissions it can invoke, and the data each tool reaches. The tests are indirect prompt injection, tool-call boundaries, and whether its MCP/function surface over-permits — a different test from the web app, which needs to be named in scope.

Next steps. See what a scoped run turns into — the scope-to-evidence roadmap, AI agent penetration testing, or book a demo and we'll scope yours in writing.