Skip to main content
Tolmo tests production. Thus, you decide which domains the agents test and which data they can modify.

​
The agents test only authorized domains

Tolmo builds your domain inventory from public DNS and certificate transparency. The inventory can include names that your organization does not own, for example a partner’s hostname or a typosquat. The inventory alone does not put a domain in scope. An authorized domain is a domain that has offensive testing enabled. An organization admin must enable offensive testing for each domain. Tolmo records the version of the testing terms that the admin accepted. The agents do not test a domain until an admin enables offensive testing for it. No run tests a hostname outside your authorized domains. An agent can produce a finding for a hostname outside your authorized domains. In this case, Tolmo holds the finding as No permitted domain and does not act on it. Define scope: domains and test accounts gives the full procedure.

​
New hosts under an authorized domain are in scope

An authorized domain includes the domain and all hostnames under it. For example, when you authorize staging.example.com, Tolmo also tests api.staging.example.com. Tolmo also tests each new host that appears under staging.example.com. Thus, Tolmo keeps up with production. When you deploy a new service under an authorized domain, the next run tests it. You do not do an extra step. A new apex domain is not in scope. It stays out of scope until you enable offensive testing for it.
Each domain row shows the number of known hostnames under the domain. Use this number to see the size of the scope before you enable offensive testing.

​
Disable testing at any time

When you disable offensive testing for a domain, the change applies immediately. The agents read the list of authorized domains when each run starts. Thus, the next run does not test the domain. The list of authorized domains is one setting for the whole organization. The Red, Blue, and Green agents all use this list.

​
Control state-changing requests

The Allow state-changing requests setting controls the PUT, PATCH, and DELETE requests of the Red team agent. These requests go to your authorized domains. For example, the agent can modify a cart or delete a record that it created.
This setting is on by default. Some environments contain test data that must not change. Before the first run on such an environment, turn off this setting. Alternatively, authorize a staging domain.

​
Limit when Blue runs

You can set testing hours for the Blue team agent. Blue does not start a run outside these hours. When the testing hours end, Tolmo stops each Blue run that is in progress. When the testing hours start again, Tolmo starts these runs again. Tolmo also starts the runs that waited.

​
You control the test accounts

To test pages behind a login, the agents use test accounts. You create and manage these accounts. You can delete an account at any time. Use only dedicated test accounts. Do not use real user accounts.

​
How Tolmo identifies its traffic

The agents test from the outside, like an attacker with no inside knowledge. Their traffic identifies itself as test traffic.

​
How Tolmo handles your data and credentials

Integration credentials stay on the Tolmo server. You can query a connected service through Tolmo. In this case, the server resolves the credentials. The server does not send the credentials to your terminal. Each finding keeps the request and the response that proved it. Thus, you can review what the agent did. For Tolmo’s security program, compliance reports, and subprocessors, see the Trust Center.