Deep Audit

What it is

Point Deep Audit at a URL, prove you own the domain, spend one Audit from your monthly allowance, and Umbra runs the entire web-app audit pipeline end to end:

1. The scan crawls the application and runs its full vulnerability module set against every endpoint it finds.
2. AI Triager judges every scanner finding: drops false positives (SQL string in marketing copy, HTML-encoded XSS), restructures the real ones into Umbra’s voice.
3. AI Explorer hunts for the things the scanner can’t see: IDOR, OAuth redirect_uri bypass, JWT confusion, mass assignment, multi-step ATO, business-logic flaws, cross-tenant access.
4. The merged finding list lands in Umbra’s existing findings UI, tied back to the scan.

Typical run: 1–3 hours. Hard cap: 10 hours wall-clock.

What’s different from a regular scanner

Regular DAST engines catch what rules catch. Deep Audit’s wedge is the AI Explorer, a bounded three-tier funnel that reads the recon model the scanner built and probes for the classes of vulnerability deterministic rules can’t reason about:

Vuln class	DAST alone	+ Deep Audit Explorer
SQLi / XSS / LFI	✅	✅ (validated, false positives dropped)
IDOR / BFLA on /api/.../{id}	❌	✅
OAuth redirect_uri bypass	❌	✅
JWT algorithm confusion	❌	✅
Mass assignment	❌	✅
Multi-step ATO (signup → reset → leak)	❌	✅
Workflow bypass / price manipulation	❌	✅
Cross-tenant UUID resource access	❌	✅
GraphQL introspection + batching	❌	✅
Privilege escalation via role-field tampering	❌	✅

The report card highlights how many findings the AI Explorer found that the scanner alone would have missed, a single number that tells you what you got beyond a vanilla DAST run.

Cost model

Item	Amount
One scan of one application	1 Audit
Each related backend in the mission (up to ten)	included
AI processing	included — never counted on top
Where it is charged	Your plan’s monthly Audit allowance

One Audit covers the entire pipeline: the scanner, AI Triager, AI Explorer, and findings persistence. The AI portion runs under an internal per-scan budget; if a pathological target exhausts it, the scan completes with whatever was already triaged and the report surfaces a “partial coverage” note. One scan is one Audit whatever the size of the application, with up to ten related backends included — so the number you plan against is the number of applications you want audited each month, not how hard any one of them turns out to be.

How to run one

1. Deep Audit in the sidebar → + New audit.
2. Enter the primary URL: https://your-app.example.com/. Multi-host missions have shipped. Add any additional hosts to the same audit (included) and they are crawled, triaged, and explored in one run that rolls up into a single report. Each host is verified independently (see the next step).
3. Prove you own the domain via one of:
   • File upload (recommended, lower friction): drop a one-line text file at https://your-app.example.com/.well-known/umbra-verify.txt containing the challenge.
   • DNS TXT record at _umbra-verify.your-app.example.com. The verifier polls every 30 seconds. Once verified, the (org, domain) pair stays trusted for 30 days.
4. Optionally:
   • Add auth credentials (cookie jar, header, basic auth, form-login), required for the ~70% of Explorer scenarios that need a logged-in session. Encrypted at rest with AES-256-GCM; the AI references them by label only (plaintext never appears in prompts).
   • Enter your own account ID on the app so destructive tests never touch other users.
   • Toggle destructive tests: opt-in for state-mutating probes (mass assignment writes, password resets, role tampering). OFF by default; with OFF the scan stays strictly read-only and skips ~30% of business-logic scenarios.
5. Launch. The scan appears in your queue; click it for live progress.

Live progress

The detail panel shows:

• Phase (jupitersec → pre_merge → triager → explorer → merge → done) and a progress bar.
• AI processing card: running cost split by phase ($Triager / $Explorer) against the scan’s AI budget.
• Partial coverage note if the budget cap fired or the scanner hit a hard error mid-run; the scan still completes with whatever was produced.
• Auth credentials: labels + kinds only (we never echo the plaintext you pasted).

Report card

Once the scan finishes, the right pane shows the headline numbers:

demo.testfire.net                                 done · 100%

AI processing                                    complete
██████████████████████████████████████████
Triager · JS Mapper · Explorer · Validator       1 Audit

Report
47 findings                                          ┌─────────┐
                                                     │    9    │
  Critical    2  ████████                            │ found   │
  High        8  ████████████                        │ by AI   │
  Medium     18  ████████████████████                │explore  │
  Low / Info 19  ████████████████████████            └─────────┘

12 scanner findings rejected by the AI Triager as false positives.

The “9 found by AI exploration” call-out is the wedge made concrete: that’s the number of real vulnerabilities Umbra surfaced that a regular scanner wouldn’t have.

Each finding is a normal Umbra finding row: same dashboard, same filtering, same lifecycle (assignee, status, due date), same Retest button. Filter by deep_scan_id to see just this scan’s findings.

How the destructive-tests toggle works

Op category	Always allowed	Allowed if toggle ON	Never allowed
Read-only probes (GET / HEAD / OPTIONS)	✅	✅	–
State changes on AI-created accounts	–	✅	–
State changes on the account you marked as yours	–	✅	–
State changes on other users’ accounts	–	–	❌
Outbound email / OAuth callbacks	–	✅ (Umbra-controlled inbox)	–
Hard destruction (DELETE, DROP, account deletion)	–	–	❌

When a scenario needs to receive an email or OAuth callback (reset flows, OAuth code exchange), Umbra provides a per-scan disposable inbox at scan-<id>@deepaudit-inbox.umbrascope.com. Outbound side effects stay inside addresses we control, never your real users.

What we don’t do in v1

• Scheduling / recurring audits (one-shot only, re-launch when you want another).
• Diff against a previous audit (use the existing finding lifecycle for fix tracking).
• Auth flows that require human MFA (TOTP, SMS, magic links). If the AI hits one, the scenario marks itself inconclusive and moves on: no skip, no false confirm.
• A free-tier preview / passive-only public scan.

What we keep / delete

• Findings: kept indefinitely under the scan, like any other Umbra finding.
• Auth credentials: encrypted at rest, retained as long as the scan’s findings are alive so per-finding Retest can re-authenticate. Revocable from the scan’s detail panel.
• Recon bundle (the scanner’s full crawl output, ~165 KB): deleted at scan finish per the retention policy. Triager keeps the per-finding PoC bytes that ended up in the published findings.
• Triager rejections (false-positive log): kept for internal quality monitoring; not surfaced to you.

Pricing recap

• One Audit per scan, covering the application and up to ten related backends. No AI add-on, no per-finding fee.
• Nothing spent if you back out before launch, or if the scan fails on a worker-side error — the Audit is returned automatically.
• AI budget ceiling reached: if hit, the scan completes with partial coverage. The Audit is still spent — the pipeline did run and did produce findings — but nothing extra is ever counted on top.