Skip to main content
The Agentic whitebox page is where you follow AI pentests and, once the Borg team has enabled it for your organisation, launch them. Open it from Testing > Agentic whitebox in the sidebar. Launch is not self-serve. The page stays visible so you can review past runs. Until the team enables agentic whitebox, launch actions and setup show Contact the team about agentic whitebox testing instead of Connect GitHub or integrations. That opens Live Support in Odin with a message ready to send. We turn it on from Operations. GitHub connect stays on Testing > PR Reviews for organisations that use reviews. The Settings menu in the header opens Pentest scope and Ignored findings. The Pentests heading counts your runs and how many are active or completed. Schedules created in Odin before scheduling moved to the team appear above the list in a Scheduled assessments section.

Starting a run

When agentic whitebox is enabled, Launch a pentest in the header opens the launch form: pick a repository, branch and folder, add a target URL, then launch. Organisations with an existing configured pentest also see Run assessment, which starts that pentest again after a confirmation dialog warning that the run can’t be paused once started.
A run cannot be paused once started. You can abort it from its card in the run list, but the assessment then has to be restarted from the beginning.
Only one run can be active at a time, so Run assessment is disabled while one is in progress. The empty run list offers Launch a pentest as well. Once you confirm, the run appears in the list with a progress bar that moves through the analysis, recon, planning, attack and report phases. Odin does not show agent logs. When the run completes, View findings on its card opens the Findings tab filtered to that run’s results, and Download report fetches the PDF once one exists. Recurring assessments are not self-serve: the team sets them up on request. Until agentic whitebox is enabled, Contact the team about pentesting opens Live Support in Odin with a message ready to send; after that, use Live Support in the Odin sidebar. See Scheduled assessments.

Run statuses

Each run has a status indicating where it is in its lifecycle: Active runs display a LIVE badge in the run list.

Run list

Run history is a list of cards, one per run. Each card shows:
  • Target domain: the primary URL being assessed
  • Repository: the source code repository used
  • Started: when the run began
  • Duration: how long it ran
  • Findings: the number of findings discovered (once the run has a summary)
Where a run covered more than one repository or domain, the card carries a +2 repos or +1 domain badge for the extras. If the run has a report, the card also has a download icon, so you can get the PDF without opening the run. A failed or timed-out run’s card says why it stopped and that you were not charged for it. If your organisation can launch pentests, members can select Start a new pentest to try again and viewers are asked to get a member to start one. If it fails again, contact support and quote the run ID shown on the card. Click any run to view its details.

Run detail

The detail header shows the target domain, when the run started, and how long it has been going. A run that failed or timed out says so in a banner under the header. Where the run covered extra repositories or domains beyond the primary ones, a Scope panel lists them all as badges. Below that are three tabs: Overview, Findings, and Attack surface.

Overview

The overview shows the phase stepper, a visual timeline of where the assessment is in its pipeline:
  1. Analyse — initial code analysis
  2. Map — crawling your application and cross-referencing with source code
  3. Plan — generating test cases from the attack surface
  4. Attack — running test cases against your targets
  5. Report — compiling confirmed findings into a report
Below the phase stepper is a live event feed that streams events as they happen during an active run. Events include reconnaissance discoveries, test case execution, and finding confirmations.

Findings

Once a run produces findings, they appear in this tab with the same filtering and detail panel as the main Findings page. The tab lists engine findings from this run together with any client tickets already on the pentest. You can filter by status, view full finding details, and export results. Client-ticket statuses can still be updated from the panel. Engine findings stay read-only until you Promote to ticket, which creates an organisation identifier so you can assign the issue, change status, and push it to your issue tracker. After promote, the engine row is replaced by the ticket. During an active run, this tab shows live finding cards as vulnerabilities are discovered in real time.

Attack surface

The Attack surface tab shows what Odin discovered about your application and how much of it was tested. It populates live during a run — the technology stack appears first, during the initial code-analysis phase; endpoints then appear as reconnaissance finds them, and their coverage updates as the attack phase progresses — and stays available after the run completes. Endpoints lists every route Odin found, with its method, path, whether authentication is required, known parameters, observed response codes, and a coverage pill: Use the filter buttons above the table to narrow it to a single coverage state. Alongside the table, two panels give context for the assessment:
  • Technology stack — the languages, frameworks, databases, and any high-risk dependencies detected in your code, plus the attack categories Odin prioritised as a result.
  • Defences observed — the security controls Odin saw while testing, such as WAF behaviour, Content-Security-Policy and CORS settings, security headers, and cookie flags. If no controls were observed, this panel says so.
Until Odin has learned anything about your application, the tab shows a “Mapping your attack surface…” placeholder; the technology stack is usually the first thing to appear.

Aborting a run

While a run is queued, running or verifying, click Abort on its card in the run list (or right-click the card and choose Abort), then confirm. The run is cancelled and its underlying job terminated. You can start a new run afterwards.

Run summary

When a run completes, a summary bar shows:
  • Duration: total time taken
  • Total findings: the number of vulnerabilities discovered
  • Severity breakdown: counts for Critical, High, Medium, and Low

Downloading reports

If a report was generated for a completed run, click the download icon on its card in the run list (or right-click the card and choose Download report) to export a PDF containing all findings, reproduction steps, and remediation guidance.

AI pentesting overview

Learn how the AI pentest works and what it tests for