An audit captures one version of a system. Production keeps moving. -[SECURE]- is an agentic security workbench for Web2 penetration testing and Web3 contract audits: define the target, follow the investigation, inspect the evidence, and test what changed after a fix.

Security researchers and development teams work from two consoles with a shared finding and verification workflow. Agents investigate in parallel. A separate verification pass challenges their claims, and the application executes the tests. The result is a finding you can inspect and revisit when the system changes.

The gap between audit and production

A web application gains an endpoint. A contract changes an access check. A release pulls in a new dependency. The previous report may still be correct about the system it examined, while saying little about the one you are about to ship.

Continuity means keeping the target, the finding and its evidence connected across that change. -[SECURE]- keeps the investigation in a task, gives each finding its own evidence and review state, and records later retests separately. For EVM projects, Diff / Replay connects this workflow directly to two versions of the code.

The useful question after a fix is whether the same proof still reproduces the problem.

Web2: from a scoped target to captured evidence

Start with a web target, an investigation goal, the scope you are authorised to test, and the constraints the work must respect. The planner uses discovered assets, observed facts and progress toward that goal to decide what to investigate next. Workers take specific directions, use browser and HTTP tools, and feed their results back into the investigation.

• Follow the investigation — an exploration graph connects observations to the follow-up work they produced. The planner tracks open, running and completed directions alongside discovered sites and endpoints. Independent directions can run in parallel; later steps in an attack path are planned around the evidence returned by earlier ones.
• Share useful observations — workers can search the execution traces of other workers in the same task. A response, an error or a newly discovered parameter can inform the next investigation even before it becomes a formal finding. The shared record gives each worker context beyond its own conversation.
• Inspect the actual traffic — with traffic capture enabled, the built-in browser uses a recording proxy, and agents can search captured exchanges and inspect request and response content. Relevant exchanges can be attached to a finding as a normal control, proof, supplementary verification or supporting evidence. Those attachments are preserved separately when temporary traffic is cleaned up.
• Keep the operator in the loop — the Mission view brings together task conversation, exploration progress, findings, asset coverage and approvals. An operator can ask for progress, add constraints or redirect an active worker before its next tool action. Configurable tool rules allow, deny or pause a call for approval.

TARGET + GOAL + SCOPE
          |
          v
PLAN -> BROWSER / HTTP WORKERS
  ^               |
  |               v
  +---- ASSETS + OBSERVATIONS
                  |
                  v
        FINDING + EVIDENCE
                  |
                  v
       INDEPENDENT REVIEW
                  |
                  v
       REPORT -> LATER RETEST

A useful finding connects a security claim to an observed boundary failure: the endpoint, the conditions that made it reachable, the action taken, the response and the impact. A different status code or reflected string alone is insufficient. Captured traffic lets a reviewer inspect that chain instead of relying on the agent's summary.

Independent confirmation is a separate step with a narrower toolset. The current Web2 verifier replays unauthenticated GET or HEAD requests, comparing a normal control with a proof request and judging fresh responses against the claimed impact. A claim that requires a login, a request body, browser execution or a state change remains unable to confirm through this verifier. Its investigation evidence stays available for review.

The task's asset summary and findings can be exported in a Markdown report. After a fix, an operator can start a retest for one finding, carrying forward its original evidence, scope and new notes. The retest records current observations and a reproduced, fixed or inconclusive outcome in its own conversation. A completed fixed retest updates the finding's disposition while retaining the original report and evidence. That is a focused follow-up assessment, distinct from the EVM test replay described below.

EVM: from a repository to a reviewable audit

In the Web3 console, choose New audit and select a repository available to the server. The workbench detects the target, prepares a separate snapshot and builds it before the audit starts. EVM projects use Foundry natively; Hardhat projects go through a best-effort conversion.

• Map the system — a code graph records functions, state and calls. An audit map tracks state-changing entry points, access and value flow, so the planner can see which entries still need review.
• Investigate in parallel — workers take review, PoC and cross-checking roles. Static analysis and available fuzzing tools add leads. The task's model configuration determines who does each job.
• Keep the finding's context — each candidate carries locations, attacker assumptions, an attack path, impact, likelihood and a proposed fix. Duplicate findings are merged while retaining their sources.
• Verify before confirming — Medium-and-above contract candidates enter independent review. A verifier proposes a test, the application runs it, and a fresh assessment checks the resulting evidence before the confirmation gate can pass.

REPOSITORY @ VERSION
         |
         v
PREPARE SNAPSHOT + BUILD
         |
         v
CODE GRAPH + AUDIT MAP
         |
         v
PARALLEL INVESTIGATION
 review / PoC / cross-check
         |
         v
MERGE CANDIDATE FINDINGS
         |
         v
INDEPENDENT REVIEW
 plan -> replay -> judge -> gate
         |
         v
FINDINGS + MARKDOWN REPORT
         |
         v
NEW VERSION -> DIFF / REPLAY

Solana: source and on-chain investigation

The Solana preview starts from either a source repository or a deployed program ID. Source targets include Anchor, native solana-program and Pinocchio projects. The workbench prepares and builds a separate snapshot, then maps instruction handlers, account constraints, state and calls. Investigation focuses on Solana's security boundaries: who must sign, which program owns an account, how a PDA is derived, and what a cross-program call is allowed to change.

• Investigate a deployed program — with an RPC connection configured, the workbench retrieves the program binary and deployment information, plus available IDL and binary-analysis material. These give researchers a starting point when source is unavailable; conclusions inferred from the binary need to remain distinguishable from source-backed observations.
• Exercise a candidate with a Rust PoC — Mollusk supports instruction-level behavior and account-state checks; LiteSVM supports transaction and signature scenarios. Tests run offline on isolated copies, retaining the test fingerprint, output and program artifact digests. Read-only account snapshots can supply chain context for the investigation.
• Compare an on-chain upgrade — select an earlier audit task to compare two saved snapshots of the same program. The upgrade comparison highlights changes to the program binary, IDL, loader and upgrade authority. It provides concrete leads for another review; it does not replay an old EVM-style exploit test against both versions.

What makes a finding confirmed

Several agents can agree on the same wrong explanation. Agreement helps direct investigation, but it does not change a finding's verification state. Discovery and verification use separate contexts, and the application captures the result of the verifier's test rather than relying on a worker's account of what happened.

For EVM, the verifier writes a Foundry test against the prepared code. The replay checks that the executed test matches the planned content, that it actually ran, and that the output contains a passing test without skipped tests. The verifier also assesses whether the real target, attacker preconditions and demonstrated impact support the claim. A compilation error, a missing dependency or an empty test run cannot establish a vulnerability.

• Confirmed — the current replay evidence supports the claim, the independent assessment upholds it, and the application gate accepts it.
• Refuted — the review found affirmative evidence against the claim, with a reason that can be inspected.
• Inconclusive or unverified — the available evidence does not settle the claim, or the finding has not passed independent review. Missing access, unsupported verification and failed setup remain visible as limits on what was established.

Severity and verification answer different questions. Impact, likelihood and attacker assumptions inform priority; replay evidence determines what has been demonstrated. Contract reports collect findings, supporting evidence, review outcomes and remediation guidance, and can be read, copied or downloaded as Markdown. Lower-severity observations can still be useful without an independent PoC confirmation.

After the fix: Diff / Replay

For an EVM follow-up, select two commits or two repository directories. Diff / Replay prepares both versions, identifies changed code and affected call relationships, and can take the bound PoCs from an earlier audit task. It executes the same test content against both snapshots and keeps the results with their version identities.

A fixed result is specific to that finding and its bound proof. It does not establish that every consequence of a change has been reviewed. The code diff and the replay answer complementary questions: what changed, and what happened to the issue you already knew about. Retests keep their own records, preserving the original finding and evidence.

Current coverage

• Web2 — browser and HTTP investigation within a defined scope. Independent replay currently covers unauthenticated GET/HEAD control-and-proof pairs only.
• EVM — Foundry repository audits, independently replayed PoCs and Diff / Replay. Hardhat conversion is best-effort; available analysis tools depend on the installed toolchain.
• Solana preview — source repositories and deployed programs can be prepared and investigated, with Rust PoCs retained as supporting evidence. Independent confirmation remains disabled until the runner can attest the exact program bytes executed, even when a test passes.
• Continuous review — tasks, version comparisons and finding retests support repeated review as a system changes. Release scheduling and CI/CD integration need to be arranged for the team's environment; an automatic release gate is not part of this workflow today.

Start with one target

-[SECURE]- is in early access as a self-hosted workbench. Start with one authorised web target or a contract repository and a clear question to investigate. For an EVM audit, include the version, build setup and scope; for a follow-up, include the changed version and the findings to replay.

The team can help map that first run to your environment, model configuration and review process. Task output can be set to English or Chinese at creation. Once there is a finding and a reproducible test, the next release has a concrete starting point for review.