What Red Team Agent does
Red Team Agent attacks your own application from the outside, the way an attacker with no inside knowledge would. It works only against domains your organization has explicitly authorized, it announces itself as a test, and it never sends anything destructive. It reports what it could actually reproduce. A finding appears because the agent ran a request and got a result it should not have — not because a scanner recognized a pattern. Every finding carries the request that proved it.The lifecycle
Four steps, and the product is arranged in that order:1
Authorized domains
You authorize what may be tested, once.
2
Automatic testing
Testing happens on a schedule, without being asked.
3
Findings
What the agent proves arrives on the Red Team Agent page.
4
Actionable fixes
Each finding carries enough context to be fixed from the page it is on.
The Red Team Agent page after a completed run. The left column is the work — the run, the three numbers it produced, and the findings themselves. The right column answers when it runs and what to look at first.
Set up Red Team Agent
Until something is in scope there is nothing to attack, so a new workspace opens on a setup checklist instead of an empty dashboard. Three tasks, each with the control that completes it.
Get ready to run. Each row links to the place that owns the setting — Red Team Agent does not keep a second copy of it.
Once a domain is authorized, the header status changes from Not set up to Watching and the agent joins the schedule. Everything after this point is adjustment, not setup.
Change the configuration later
Open Settings in the page header. One dialog holds what the agent tests, how often it tests, and where it reports — the three things you might come back to change.
Settings: domains in scope, the run cadence, and notifications, in one place.
Authorize the domains it may test
Domains in scope is the list of domains Red Team Agent is allowed to attack. It is the only thing that decides where the agent may act: a hostname that is not covered by an entry on this list is never touched, on any run.Why authorization is required
Your domain inventory is built from public DNS and certificate transparency, so it lists names your organization does not own — a typosquat, a partner’s hostname, something a former employee still holds. Appearing in the inventory is not ownership, and it is not permission to attack. Authorization is therefore two separate steps, in this order:1
Verify ownership
Tolmo gives you a
tolmo-domain-verification=… TXT record to publish in the domain’s DNS zone. Only someone who controls the zone can publish it, which is the point — it cannot simply be asserted.2
Permit the domain
A separate, explicit decision that offensive testing is allowed against it. Verifying a domain does not authorize anything on its own.
Which domains Red may test. Each row shows how many known hostnames the entry covers, so a grant is concrete rather than abstract.
What an entry covers
An entry covers the domain and everything beneath it. Permittingstaging.example.com permits every hostname under it, which is how people already think about a staging environment. The row shows the hostname count so you can see the size of what you are agreeing to.
Each domain in the list reads as one of three states:
- Red may test these — verified and permitted. In scope.
- Ownership proven, not authorised — verified, but deliberately not permitted.
- Something beneath it is authorised — the domain itself is out of scope, but an entry below it is in scope.
This is one setting for the whole organization, not a per-agent one. Blue and Green read the same list. Revoking an entry takes effect immediately: the agents read the list at the moment they run, so the next run is already out of scope. Revoking keeps the ownership verification, so you never have to re-publish a DNS record to undo a policy decision.
Where to manage it
Two routes to the same list. Use Change what is permitted inside Settings when you are already adjusting the agent, or Manage on the Domains card to open the domain inventory, where the permission lives as a property of the domain.Understand the run schedule
Red Team Agent tests every 10 days, automatically, across every authorized domain. A full run takes roughly ninety minutes, and its findings take days to work through — ten days leaves room to close them before the next run asks again. The cadence is fixed in this release. It is stated on the Run schedule card and in Settings as a fact rather than offered as a choice, because there is no control that changes it.
The Run schedule card. Values are relative — the question a reader has is how long, not which date.
View all on the card, and View runs in the header, both open the full run history. See View run history in Mission Control.
Choose where results are announced
Runs happen without you watching, so notifications are how you find out. Open Settings in the page header and use the Notifications grid: events down the side, channels across the top. One cell answers “does a completed run reach Slack”.
Three events, two channels. Run started is off by default on both — a run every ten days that announces itself twice is how a channel gets muted.
Channels are Email and Slack. The destinations — which address, which channel — are set once for the whole organization in Notification settings, not per agent. The panel names the current destinations so you can see where a toggle will actually send something.
A run that finds nothing still sends a Run completed notification if that event is on. A clean result is a result, and silence is indistinguishable from a run that never started.
Understand your results
Three numbers sit above the findings table. They describe the same set of issues at three different levels of certainty, so reading them left to right tells you how much of the last run is settled.
Discovered, Needs review, Validated.
After a run that found nothing, all three read zero and the table says so explicitly rather than looking empty. A run that completed clean is the product working.
Above the numbers, a line about the run that produced them: which run, how many paths it ran, how long it took, and against what.
Review findings
The findings table lists what the last runs produced, most severe first. Four columns: Severity, Finding, Stage, and Run.
Severity leads its own column so the value you scan for is in a line. The finding carries its affected endpoint underneath the title; the stage and the run that found it sit on the right.
Narrow the list
- Search findings or targets matches both the finding title and the affected address, so you can search by endpoint as well as by name.
- Stage, Severity, and Recent runs filter the list. Each choice you make becomes a tag underneath that you can drop on its own.
Severity
Critical, High, Medium, and Low, on the same scale and in the same colors as the rest of Tolmo. It is the first column and the table sorts by it, so the row at the top is the one to open.Stage
The stage says where a finding is in its life on this page.The affected target
Under each title is the address or endpoint the finding is about — a full URL, or a method and path such asPOST /api/auth/reset-password. The Run column names the run that produced it, which is the link back into the run history.
Actionable findings keeps the most urgent one in front of you, so you do not have to decide the order yourself.
Take action on a finding
Click a row. The finding opens in place, underneath the row it belongs to — the table stays where it is, so closing it puts you back exactly where you were. It opens on one layer, which answers four questions in order:- What happened — what the agent did, and what came back.
- Why it matters — who could do this, and what they would get.
- Key evidence — the one request and response that carries the argument.
- Recommended fix — the change that closes it.
A critical finding, opened. Status and address come first because they decide whether the rest is worth reading; the next move sits top right, reachable the moment the panel opens.
Answer a finding that needs review
A Needs review finding carries three answers in its own panel. There is no fourth.
Accept, Dismiss and Defer, beside Copy fix prompt.
A decision stays decided. What you dismiss does not return as a new finding on the next run, and Undo is there beside the decision if you clicked the wrong one.
Copy a fix prompt
Copy fix prompt is the primary action on every finding. It copies the whole finding to your clipboard as a single instruction, written for a coding agent, scoped to the affected endpoint.
Copy fix prompt sits top right of the open finding. It confirms with Copied.
See the complete technical detail
See more, at the bottom of an open finding, unfolds the technical record. The first layer is for deciding and acting; this layer is for whoever has to reproduce the issue or review the fix.
Behind See more: reproduction, the full request and response, technical context, impact and remediation detail.
The hierarchy is deliberate: quick view to understand and act, See more to investigate. Show less folds it back. Not every finding has a second layer — where there is nothing more to show, the control is not there.
View run history in Mission Control
The Red Team Agent page shows the current state: the last run, and what it left you to work on. The full operational history lives in Mission Control, which answers a different question — not “what security issues do I have” but “what have my agents been doing”. View runs in the page header and View all on the Run schedule card both open Mission Control with Red Agent already applied as a filter, so you land on your runs rather than on every run in the organization.
Agent runs, filtered to Red. The filter is part of the link, so the filtered view is shareable.
Expand a run to see the findings it touched, by name. A finding is referenced rather than copied, so the same issue crossing Blue, Red, and Green stays one finding with several runs against it. The filter chips at the top switch between agents and statuses, and All runs clears them.
A failed check is not a finding. It is a probe that could not complete, which is a gap in coverage rather than a vulnerability — the Result column reports it so it does not pass unnoticed.
Next steps
Manage findings from the CLI
Create, triage, and update findings with
tolmo findings.Threat models
Download threat model pipeline runs and artifacts.