Scenario 1
Preview — execution disabledMulti-agent analysisIntermediateMulti-Agent Vulnerability Analysis
A pipeline of narrow agents turns raw tool findings into checked evidence — and keeps everything unverified marked UNKNOWN.
Security tools — scanners, SAST/DAST engines, dependency auditors, fuzzers — produce findings, not facts. A finding is a claim about a target: a tool believes a property holds, under assumptions that are often implicit and sometimes wrong. This scenario is a static architectural walkthrough of how a small pipeline of narrow agents consumes that output: ingesting findings as claims, normalizing them to a common shape, correlating independent signals, classifying risk, and then handing every claim to a deterministic verifier that promotes it to evidence only when a specific, stated property is actually settled.
The ordering principle is honesty about what is known. A tool reporting a vulnerability is treated as a hypothesis to be checked, never as truth to be trusted. A claim the verifier can settle under its stated assumptions becomes evidence with a PROVEN / NOT PROVEN verdict for that property; everything the verifier cannot settle stays UNKNOWN and is reported as such. Crucially, an empty scanner result never becomes "no vulnerabilities" — absence of findings is not evidence of absence.
Honesty
This is a conceptual architecture with a synthetic trace. Nothing executes: no scanner is run, no target is touched, and the findings, correlations and verdicts below are illustrative. The point is the mechanism — claims in, checked evidence or an explicit UNKNOWN out — not any score or count.
Preview Mode — Execution Disabled
This laboratory is currently available for architectural exploration and educational demonstrations only. Live agent execution and security testing are disabled. Operational access requires prior explicit authorization from RavenRootviel.
Architecture
Components and flows
The agents, services, verifiers, policy engines and evidence stores in this scenario, and how they connect. Drag to pan, scroll to zoom, and select any component for its role, inputs and outputs.
Agents
Agents and responsibilities
Each agent has a narrow responsibility, explicit inputs and outputs, and — crucially — its own authorization posture. Reasoning is never authorization.
Ingestion Agent
Reads the raw output of one or more security tools and records each finding as an untrusted CLAIM, preserving the tool, version, target and the finding exactly as emitted. It asserts nothing about whether a claim is true.
- Inputs
- Tool output / scan results (untrusted) · Target descriptor
- Outputs
- Findings as claims, each tagged with its source tool and provenance
- Tools
- Report parsers (SARIF/JSON/plain-text, deterministic)
- Authorization
- None — read-only ingestion; it transcribes and tags, it decides nothing.
- Verification
- Every claim carries the tool and version that produced it; provenance is recorded from the ingestion path, not inferred from the finding text.
- Possible failures
- Unparseable or truncated tool output — fails closed by recording a parse error, not by dropping findings silently.
Normalization Agent
Maps each heterogeneous claim onto a common schema — target, component/location, weakness class, affected version range — so claims from different tools can be compared without losing their origin.
- Inputs
- Findings as claims
- Outputs
- Normalized claims on a shared schema (origin preserved)
- Tools
- Weakness taxonomy mapper (e.g. CWE class lookup, deterministic)
- Depends on
- ingestion
- Authorization
- None — a structural transformation; it reshapes claims, it does not judge them.
- Verification
- Normalization is a reversible mapping: the original finding is retained alongside the normalized form, so a mismatch can be detected and reviewed.
- Possible failures
- A claim that does not map cleanly to the schema — kept as-is and flagged "unnormalized" rather than force-fit into the wrong class.
Correlation Agent
Groups normalized claims that refer to the same component and weakness, noting where independent tools agree, where only one tool reports, and where tools contradict each other. Agreement raises priority for checking; it is not itself proof.
- Inputs
- Normalized claims
- Outputs
- Correlated claim groups with agreement / single-source / conflict annotations
- Tools
- Deterministic grouping on (component, weakness class, version range)
- Depends on
- normalization
- Authorization
- None — produces groupings and hypotheses, not verdicts.
- Verification
- Correlation is explicitly hypothesis-level: a group is a candidate to verify, and a conflict is surfaced, never resolved by majority vote.
- Possible failures
- Over- or under-grouping from inconsistent component naming — surfaced as low-confidence groups for the verifier and for review.
Risk Classification Agent
Conceptual exampleAttaches a provisional severity and exploitability band to each correlated group using a published scoring scheme, so checking effort can be ordered. The classification is advisory and clearly marked provisional until a property is verified.
- Inputs
- Correlated claim groups
- Outputs
- Provisional risk bands per group (advisory)
- Tools
- CVSS-style scoring reference (deterministic mapping)
- Depends on
- correlation
- Authorization
- None — advisory ranking only; it cannot promote a claim or close a finding.
- Verification
- A risk band is never treated as evidence that the vulnerability is real; it only prioritizes which claims the verifier examines first.
- Possible failures
- Mis-prioritization from an incomplete claim — bounded impact, because classification changes order, not truth.
Verifier (deterministic)
The evidence boundary. For a given claim it checks one specific, stated property under explicit assumptions. If the property is settled, the claim is promoted to evidence with a PROVEN or NOT PROVEN verdict for that property; if it cannot be settled, the claim stays UNKNOWN.
- Inputs
- Correlated claim groups · Provisional risk bands · Stated assumptions / check definition
- Outputs
- Evidence items (PROVEN / NOT PROVEN for a named property) · UNKNOWN verdicts for unsettled claims · Verification record
- Tools
- Deterministic verification routines (property + assumptions → verdict)
- Depends on
- correlation · classification
- Authorization
- This IS the evidence boundary. A claim becomes evidence only here, only for the property actually checked, and only under the stated assumptions. Deny-by-default: unsettled ⇒ UNKNOWN.
- Verification
- Each verdict is a pure, reproducible function of (claim, property, assumptions) and is logged with those inputs; a verdict settles one property, never that the whole target is secure.
- Possible failures
- A property the routine cannot decide — returns UNKNOWN by construction, never a guessed PASS.
Workflow
Processing and decisions
The ordered path from input to recorded decision.
- 1
Ingest findings as claims
The raw output of each security tool is read and every finding is recorded as an untrusted claim, tagged with the tool, version, target and the finding exactly as emitted. Nothing is accepted as true at this stage.
- 2
Normalize to a shared schema
Each claim is mapped onto a common shape — component, weakness class, affected version range — while the original finding is retained so the mapping can be checked and reversed.
- 3
Correlate independent signals
Claims about the same component and weakness are grouped. Agreement between independent tools raises a group for checking and contradictions are surfaced; neither agreement nor count is treated as proof.
- 4
Classify risk provisionally
A published scoring scheme attaches an advisory severity band to each group so verification effort is ordered sensibly. The band is explicitly provisional and promotes nothing.
- 5
Verify one property at a time
The deterministic verifier checks a specific, stated property under explicit assumptions. Settled claims become evidence with a PROVEN or NOT PROVEN verdict; anything it cannot settle stays UNKNOWN.
- 6
Generate an honest report
The report renders checked evidence with its property and assumptions alongside the explicit UNKNOWNs, every item carrying its provenance. The absence of findings is never reported as the absence of vulnerabilities.
Example execution
Walk through an illustrative trace
A synthetic, predefined sequence — step forward and back to see what each component does, the evidence it produces and the decisions taken. This is a conceptual/synthetic trace, not an executed experiment, and it cannot be run live in this preview.
Step 1 / 6 · Ingestion Agent
Synthetic traceFindings ingested as claims
Two findings arrive for a sample service "billing-api": Scanner A claims a vulnerable version of a dependency "libparse 1.2.0" (weakness: known-vulnerable component); Scanner B claims a possible SQL injection in /invoices. Both are recorded as untrusted claims with their source tool and version.
▤ evidence: ingested-claims
Evidence
Evidence in this scenario
What is recorded, of what kind, with what integrity property and from where. Demonstrative data — not cryptographic evidence of a real system.
Ingested findings as claims
Untrusted claimsIntegrity: Transcribed verbatim with source tool and version; not treated as true
Provenance: Ingestion Agent over tool output (synthetic)
Verification record
Deterministic verdict (PROVEN / NOT PROVEN / UNKNOWN)Integrity: Pure function of (claim, property, assumptions); settles one property, demonstrative here — not cryptographic evidence of a real system
Provenance: Verifier (deterministic)
UNKNOWN register
Open itemsIntegrity: Explicitly unsettled claims; retained, never silently closed or called safe
Provenance: Verifier (deterministic)
Security controls
Authorization, validation and containment
The mechanisms that make the scenario safe by design, independent of what any model concludes.
Claims, not truth, on ingestion
Every tool finding enters as an untrusted claim tagged with its source and version; no finding is accepted as a fact at any stage before verification.
Deterministic verification before promotion
A claim becomes evidence only when the verifier settles a specific, stated property under explicit assumptions, with a reproducible PROVEN / NOT PROVEN verdict for that property alone.
UNKNOWN by default
Anything the verifier cannot settle stays UNKNOWN and is reported as such; an empty scanner result is never rendered as "no vulnerabilities", because absence of findings is not evidence of absence.
Provenance on every item
Each claim, correlation, verdict and report line carries its origin — which tool, which property, which assumptions — so any conclusion can be traced and re-checked.
Failure conditions
What can go wrong — and the expected behaviour
Honest failure modes and the containment or recovery that keeps a failure from becoming an unauthorized effect.
Duplicate or contradictory findings
Two tools report overlapping or conflicting claims about the same component.
Recovery
Correlation groups and annotates them (agreement / single-source / conflict); conflicts are surfaced for the verifier and review, never resolved by majority vote.
Verifier cannot settle a claim
The property a claim asserts cannot be decided under the available assumptions.
Recovery
The claim stays UNKNOWN by construction and is carried forward in the UNKNOWN register; it is never promoted to a guessed PASS or quietly dropped.
Normalization mismatch
A claim is force-fit to the wrong weakness class or component by inconsistent naming.
Recovery
The original finding is retained alongside the normalized form, so the mismatch is detectable; unmappable claims are flagged "unnormalized" rather than mapped incorrectly.
Technical notes
Design considerations, limitations and references
- This is a conceptual architecture with a synthetic trace; nothing is executed — no scanner is run and no target is touched.
- A verdict settles one property under stated assumptions; it never establishes that the whole target is secure, and PROVEN / NOT PROVEN / UNKNOWN are kept strictly distinct.
- The Risk Classification Agent here is a conceptual example used only to order checking effort; it is advisory and promotes nothing.
References
- OWASP Top 10
- MITRE ATLAS
- CVSS v4.0 specification
Try this lab
Run it — coming soon
Interactive execution of this scenario is not part of the preview. When it is enabled, it will run on controlled, authorized scenarios only.
Live execution is not available in this preview. Access will require explicit authorization from RavenRootviel.
Authorized Access Only — Live Security Testing
Live security testing and agent execution require prior explicit authorization from RavenRootviel. The current preview provides educational content and non-operational demonstrations only. Browsing the educational content is public; operational use of the labs will require express authorization when it is enabled in a later phase. Access & use policy.