Why every Countermind starts with a written scope: what goes into it, who signs it, and what an agent does when it reaches the edge.
- Published
- Updated
- Reading time
- 6 min read
- By
- Enis Getmez, CTO
In this guide
People expect the interesting part of our work to be the agents. It is not where we start. Every Countermind begins with a few pages of plain writing that say what may be tested, by whom, when, and what is off limits. Nothing runs until that document is signed.
This is not ceremony. Autonomous agents are fast, tireless and literal, and those are exactly the qualities that make a boundary matter. A scope is the boundary.
Why the scope comes first
Testing a system you do not own, without written permission, is not security research. It is unauthorised access, in most jurisdictions and in every contract I have read. The scope is what turns the same technical activity into agreed work.
It does three jobs at once. It grants authority, from someone entitled to give it. It gives both sides a legal footing if anything is ever questioned. And it builds trust: you know precisely what we will touch, and we know precisely what we may not.
What goes into a scope
A good scope is specific enough that a stranger could read it and say, for any request, whether it was allowed. Ours always covers the same ground.
- Targets. Named hosts, domains and APIs, such as app.northwind.example and api.northwind.example/v2. Not "the platform".
- Environments. Staging, production, or both, and which data each one holds.
- Test accounts. One per role we are asked to test, created by you, owned by you, revoked by you at the end.
- Time windows. When testing may run, in which time zone, and who to call if it must stop.
- Forbidden actions. What we will not do even inside the targets.
| Forbidden action | Why it is excluded | What we do instead |
|---|---|---|
| Changing production data | Your customers' records are not ours to alter. | Prove access with read evidence or test-account data. |
| Denial of service | Availability is yours to protect, not ours to test by accident. | Note rate-limit gaps as findings without load. |
| Social engineering | Your people did not sign the scope. | Excluded unless separately agreed in writing. |
| Third-party systems | Your payment or email provider is not party to the contract. | Record the dependency and stop at your boundary. |
Who signs it
Two signatures, every time. One from someone at your company with real authority over the systems named: usually the CTO, a head of engineering or a founder. One from Zaaf. An enthusiastic engineer is not enough, and neither is a sales contact who has never seen the infrastructure.
If you host on a cloud provider, their acceptable use terms still apply, and we read them. If a target belongs to a subsidiary or a client of yours, the person who signs must be able to authorise testing on their behalf. We ask, and we write the answer down.
What happens at the edge
Real systems leak beyond their documentation. An agent working on app.northwind.example will find a reference to legacy.northwind.example, or a storage bucket nobody mentioned. This is where a literal machine needs a firm rule, and ours is simple.
- StopThe agent sends nothing to the new target. Discovery is not permission.
- RecordIt logs what it found, where it found it, and why it looks related.
- AskA researcher reviews it and asks you. A scope change is made in writing, or not at all.
Often the forgotten host is the most valuable thing we report, precisely because nobody knew it existed. You still get to decide whether we look at it.
Evidence you can trace
Every request an agent sends is tied to the scope record that allowed it: the target, the window, the account and the clause. If you ask why we touched a given endpoint at a given minute, the answer is a lookup, not a recollection.
That same record travels with each finding. When a researcher signs a finding, they are signing that it was found inside the agreed boundary, with the agreed access, inside the agreed window. A reviewer at your buyer can rely on that.
Before testing starts
Is your scope ready?
Common questions
Can testing start before the contract is signed?
No. Nothing is sent to any target until the contract and the written scope are signed by both sides.
What happens if an agent finds a system that is not in scope?
It does not touch it. It records what it found and a researcher asks you. Testing extends only after a written scope change.
Who should sign the scope on our side?
Someone with real authority over the named systems, usually a CTO, head of engineering or founder, and able to authorise testing on behalf of any subsidiary or client that owns a target.
Do you test production?
Only if the scope says so, and never by changing production data or degrading availability. Many engagements use staging plus read-only checks in production.
NoteThis describes how Zaaf scopes its own engagements. It is general guidance, not legal advice; your contract, the signed scope and your own counsel govern what is authorised.