Core Components of the VAP‑T Architecture#
VAP‑T’s backbone is a continuously refreshed symbolic scene graph built from RGB‑D streams, verified by vision‑language model (VLM) VQA queries, and fed into an integrated task‑and‑motion planner that produces concrete motion primitives. This graph captures objects, doors, and network‑visible assets as nodes, while edges encode spatial and logical relationships, enabling the planner to reason about preconditions and expected effects before each action. When a VQA query such as “Is the target port 443 open?” cannot be answered from the current view, the system triggers active viewpoint selection, re‑captures the scene, and updates the graph. The planning layer then invokes TAMP to translate the enriched graph into executable motion commands. The same graph is exported to the security side, where each node represents a concrete asset (e.g., a discovered endpoint) that the Generator can reason about. The approach mirrors the VAP‑TAMP framework’s use of scene graphs and VLM‑driven verification for robotic tasks https://vap-tamp.github.io/vap-tamp/.
Scene‑Graph Construction#
# Pseudo‑code for converting RGB‑D to a scene graph node list
points = capture_pointcloud()
instances = detect_instances(points) # returns class, bbox
for obj in instances:
G.add_node(obj.id, type=obj.label, pose=obj.pose)
G = add_spatial_edges(G)
The graph is persisted as JSON and versioned after each perception tick.
Deterministic 4‑Node Pipeline#
The pipeline is a strict directed‑acyclic graph (Mapper → Generator → Executor → Validator) where each node reads only upstream SQLite tables and writes downstream, guaranteeing deterministic progression and reproducibility. The Mapper performs pure reconnaissance, populating an endpoints table with subdomains, open ports, and service banners using tools such as subfinder and nmap. The Generator consumes unprocessed rows, applies LLM reasoning to craft targeted test cases (, , HTTP‑desync, postMessage) and stores them in a test_cases table. The Executor mechanically fires each request through a headless Burp Suite instance, recording raw responses in execution_results. Finally, the Validator compares responses against the Generator’s expected behavior, reconstructs a reproducible PoC, and writes verified findings to a verified_findings table. This architecture follows the deterministic 4‑node design that achieves near‑zero false positives https://dev.to/kenzman/beyond-free-roaming-agents-architecting-a-deterministic-4-node-graph-pipeline-for-3ip1.
Example Mapper Output (SQLite)#
INSERT INTO endpoints (id, host, port, service)
VALUES (1, 'api.example.com', 443, 'https');
Generator‑Created Test Case#
{
"id": 101,
"endpoint_id": 1,
"method": "POST",
"path": "/login",
"payload": "username=admin'--&password=any",
"expected": "SQL error"
}
Executor cURL Call (replay‑verified)#
curl -s -X POST https://api.example.com/login \
-d "username=admin'--&password=any" -o /tmp/resp.txt
CVSS Vector for a Successful #
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Integration Flow: From Perception to Exploit Validation#
Perception drives security: before every robot action the planner queries the scene graph, after execution it validates observed effects, and any discrepancy launches an active perception loop that refreshes the graph for the Generator. When the updated graph indicates a newly exposed HTTP endpoint, the Generator instantly creates a matching test case. The Executor runs the request, and the Validator’s replay‑verified PoC is fed back as evidence to the perception module, allowing the robot to treat the discovered vulnerability as part of its world model (e.g., marking a door as “locked by exploit”). This closed‑loop mirrors the VAP‑TAMP violation‑handling mechanism where replanning follows situation assessment https://vap-tamp.github.io/vap-tamp/.
Data Flow Diagram (simplified)#
[Perception] → Scene Graph → [Generator] → Test Cases → [Executor] → Responses → [Validator] → PoC → Feedback → [Perception]
The feedback includes a hash of the PoC payload stored in the graph, enabling the robot to reason about exploitability when navigating physical spaces.
Zero‑False‑Positive Guarantees#
Every finding is replay‑verified, the state machine enforces strict upstream‑downstream contracts, and Merkle‑root anchoring provides tamper‑evidence, collectively delivering zero‑false‑positive confidence. Before a finding is reported, the Validator automatically re‑executes the exact request‑response chain in Pentrova’s sandboxed PoC environment; only if the replay matches the expected behavior is the finding persisted. The deterministic tick‑engine guarantees that no node can skip a step, eliminating nondeterministic drift that plagues legacy scanners. Periodic Merkle‑root commits of the SQLite database are anchored to an external timestamping service, creating an immutable audit trail. Additionally, a statistical cross‑target memory records hit‑rates for each exploit vector (e.g., header spoofing 85% success on fintech targets), allowing the platform to assign confidence scores and prioritize remediation.
Merkle‑Root Commit (pseudo‑code)#
root = merkle_tree.hash_all_rows('verified_findings')
anchor_external(root) # e.g., public blockchain timestamp
Confidence Scoring Example#
| Vector | Hit‑Rate | Confidence |
|---|---|---|
| 0.92 | High | |
| 0.78 | Medium | |
| PostMessage | 0.65 | Low |
Practical Deployment on the Pentrova Platform#
Mapping VAP‑T to Pentrova’s products is straightforward: the Mapper becomes the Web Scan engine, the Generator aligns with API Scan, the Executor runs inside the sandboxed PoC environment, and the Validator leverages the ReplayVerifier component. The Authorization Matrix and DOM‑ canary taint features are used as pre‑condition checks in the perception layer, ensuring that only authorized actions are attempted and that ‑related state changes are reflected in the scene graph. CI/CD integration is achieved via the Platform product, which triggers a deterministic scan on every commit using the /scan-target tick command; compliance tags are auto‑applied from the Compliance solution, mapping findings to PCI DSS, ISO 27001, HIPAA, and GDPR controls. This end‑to‑end flow gives developers continuous, replay‑verified security feedback without manual triage.
Sample CI/CD Hook (GitHub Actions)#
name: Pentrova Scan
on: [push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Pentrova
run: |
curl -X POST https://api.pentrova.com/scan-target \
-H "Authorization: Bearer ${{ secrets.PENTROVA_TOKEN }}" \
-d '{"target":"https://app.example.com"}'
The scan produces a deterministic report with replay‑verified PoCs, automatically tagged for compliance.
FAQ#
What is VAP‑T and how does it differ from traditional ? VAP‑T augments classic vulnerability‑assessment pipelines with robot‑style active perception and a scene‑graph world model, enabling dynamic environment awareness and on‑the‑fly test‑case generation, whereas traditional relies on static asset lists.
How does active perception reduce false positives in automated penetration testing? By continuously validating preconditions and effects with VLM‑driven VQA queries, the system only generates test cases for assets it can confirm as present, preventing spurious scans of non‑existent endpoints.
Why is a deterministic 4‑node DAG important for zero‑false‑positive guarantees? The DAG enforces strict read‑write contracts and deterministic ticks, ensuring every finding passes through a reproducible validation step before being reported.
Can the VAP‑T architecture be integrated with existing CI/CD pipelines? Yes; Pentrova’s Platform exposes a /scan-target endpoint that can be invoked from any CI/CD system, delivering deterministic, replay‑verified scans on each commit.
What evidence does the Validator provide to satisfy audit and compliance requirements? The Validator outputs a fully reproducible PoC—including request, response, and execution logs—anchored with a Merkle‑root, and maps each finding to relevant compliance controls via the Compliance solution.