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.
The 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, so every stage runs in a fixed order. 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 the request and response as evidence, and writes verified findings to a verified_findings table. This architecture follows the 4‑node design described in 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#
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 confirmed finding, with its captured request and response, 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.
Keeping Unconfirmed Findings Out of the Queue#
Every finding in your queue was confirmed by AI review of evidence captured from your target, and the state machine enforces strict upstream‑downstream contracts. Findings that are not confirmed never reach your queue. Where a request is a safe GET or HEAD, Pentrova re‑sends it once from a fresh HTTP client and compares the response with a clean baseline; the result is one piece of evidence the AI review weighs, never a verdict on its own, and state‑changing requests are never re‑sent. The state machine ensures that no node can skip a step. 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.
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 sends its exploit checks from an isolated sandbox that can reach only the hosts you have authorized, and AI review of the captured evidence plays the Validator’s role. 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 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 security feedback, with every finding confirmed by AI review of evidence captured from your target, 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 report of findings confirmed by AI review of evidence captured from your target, 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 4‑node DAG important for keeping false positives out of the queue? The DAG enforces strict read‑write contracts and ordered ticks, so every finding passes through a validation step before it is reported: in Pentrova, AI review of evidence captured from the target, and findings that are not confirmed never reach your queue.
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 a scan on each commit, with every finding confirmed by AI review of evidence captured from your target.
What evidence does the Validator provide to satisfy audit and compliance requirements? Where a finding has a captured HTTP exchange, it includes the request and response, which you can copy as cURL or raw HTTP or download as Markdown or HAR, and Pentrova maps each finding to relevant compliance controls via the Compliance solution.