Begin with authority
Record the system owner, the person granting permission, and the relationship between them. Vendors, subsidiaries, shared infrastructure, and customer-managed environments create boundaries that a simple domain list can hide.
Describe assets as behavior
List hosts and APIs, then describe important flows: tenant administration, payments, exports, file processing, password recovery, support impersonation, and machine-to-machine access. This gives testers a map of consequences, not just endpoints.
Write exclusions in plain language
If production data changes, email delivery, destructive actions, account lockouts, cost-incurring API calls, or denial-of-service techniques are excluded, say so directly. Add rate ceilings and time windows where the system is sensitive.
Provide test identities
Purpose-built accounts with different roles make authorization checks safer and more useful. Prefer synthetic data. Explain which account may act on which records so a cross-tenant result can be recognized without touching real customer information.
Define stop conditions
Name the contact and channel for unexpected impact. Agree what stops testing: elevated error rates, data-integrity concerns, out-of-scope redirects, third-party dependencies, or observed access to real sensitive data.
Treat scope changes as changes
New hosts, credentials, techniques, or time windows require an explicit amendment. An agent’s discovery is evidence to review—not permission to expand.