Verified Findings

Trace doesn't just report what might be exploitable; it proves it. For findings where it's safe to do so, Trace's validation agents reproduce the exploit against your running application, using the environment and credentials you've configured.

Why this matters

Reasoning about code statically produces plausible-but-wrong findings: an "IDOR" that a middleware actually blocks, an "injection" the ORM already parameterizes, an "auth bypass" gated by a check the analyzer didn't model. Every one of those is a false positive that costs an engineer time to chase down.

Trace closes that gap by exercising each finding against the real system. If the exploit fires, you get proof. If it doesn't, the candidate is dropped or held for human review rather than shipped. What reaches your dashboard is what's genuinely exploitable in your deployment, not a list of theoretical risks to triage.

The primitives: application, environment, credential

To validate against your live stack, Trace models the target with three primitives. You set them up from the dashboard or the CLI before an engagement runs.

• Application: the app under test. It's the scope object a pentest runs against, and it links to the source repository Trace reads for whitebox analysis.
• Environment: a deployed instance of that application (e.g. staging, production) with a reachable URL. Validation runs against the environment you designate, typically a staging or pre-production stack, so exploitation never touches production.
• Credential: how Trace signs in to the environment as a real user. Most often this is an email and password, but Trace also supports bearer or JWT tokens, session cookies, API keys, and passphrases. For logins that email a magic link or a one-time code, Trace's agents have a dedicated inbox, so they can receive that message and complete the sign-in exactly like a real user would. Credentials are stored in a managed secret store, scoped to the environment, and never returned once set.

Together these tell the validation agents where the application runs and how to log in, the two things you need to actually drive an exploit against it.

The validation phase

When a candidate finding comes out of analysis, Trace hands it to a validation sub-agent running in an isolated, sandboxed runtime with scoped, short-lived access:

1. Read the finding. The agent takes the attack vector, the affected endpoint or code path, and the expected impact.
2. Authenticate. It logs in to the target environment using the configured credential, establishing a real session as the relevant user or role.
3. Attempt the exploit. It sends the request, payload, or sequence of operations the finding describes against the running application.
4. Observe the outcome. If the impact is confirmed (it reads another tenant's data, escalates privilege, or injects successfully), the finding is marked verified and the reproduction is captured. If nothing reproduces, the candidate is dropped or routed to human review instead of being reported.

Each validation agent runs in a sandbox with only scoped, short-lived credentials, so exploitation stays contained and auditable. See How Trace Handles Your Data.

What a verified finding includes

For findings validated through exploitation, the record carries:

• A reproduction artifact: the exact request, payload, or sequence of operations that triggered the issue.
• A recorded session: depending on the finding type, an HTTP traffic capture, a video of the browser flow, or a transcript of the agent's exploitation steps.
• A confirmed impact: the data, capability, or access actually gained, rather than what analysis inferred.

What gets validated

Trace validates findings it can reproduce safely: anything that could cause data corruption, persistent state changes, or production impact is not exploited. The classes validated against a live target today include:

• Injection (SQL, command, template) reachable via the application's request surface.
• Cross-site scripting (XSS): reflected, stored, and DOM-based.
• Authentication and authorization bypasses: IDOR, missing authorization checks, and role-confusion bugs.
• Server-side request forgery (SSRF) and open redirects.

Findings outside that scope still ship with full code-level verification and threat-model context (the attack vector, data flow, and impact), substantiated with code citations and reviewed by a security expert, just without an exploitation artifact.