Contact Sales Request Demo

DIRVA Dashboards

Live Security Pages. Built and Kept Current by Agents.

Describe what you want to watch in plain language. A design agent builds the page, an action agent keeps it current, and anyone with the link sees the security picture as it is right now — not a point-in-time report.

Request a DemoContact Sales

Dashboards

What it is

Dashboards are always-on, live security pages that DIRVA AI's agents build and keep up to date. You describe in a chat what you want to watch: an attack surface, vulnerability exposure, code and supply-chain risk, or configuration compliance.

A design agent works through it with you — what to show, which systems and scans feed it, and how and when it refreshes. It checks everything against your real environment, then builds the page. From then on an action agent, or an agent team, refreshes it on a schedule or when someone presses a button on the page.

It runs on DIRVA AI's own security tooling:

  • Port and service scanning with OS fingerprinting
  • CVE intelligence
  • Dependency and code scanning with secret detection
  • SSH, PowerShell, NETCONF and APIs
  • Azure, Microsoft 365 and GitHub connectors
External attack surface · production ranges Refreshed 12s ago · next run 06:00 · run #418
Critical3+1 since last run
High11−2 since last run
Open ports184+2 new
Hosts62+1 newly exposed
Changed since last run
  • New10.40.12.7 TCP/22 open · OpenSSH 9.6 · Ubuntu 22.04
  • New10.40.18.3 TCP/8443 open · nginx 1.24
  • Hostvpn-edge-02 first seen this run
Needs attention first
  • 10.0CVE-2024-3094 build-runner-07 Investigated · evidence · fix proposed
  • 9.8CVE-2024-6387 vpn-edge-02 Investigated · evidence
  • 8.1CVE-2023-44487 api-gw-03
Rescan now Re-verify this finding Collect evidence Buttons run the instructions you wrote · every run keeps its full transcript

How it works

From a sentence to a living page.

Two agents with two different jobs — one designs, one runs. Neither can do the other's job.

STEP 01

Describe

Tell the design agent what you want to watch, in a chat. It collects what it needs to know.

STEP 02

Design & validate

It settles what to show, which scans and systems feed it, and the refresh schedule — then runs a validation pass against your live environment before anything is built.

STEP 03

Build

The page is generated: charts, tables, findings, and any action buttons you defined, with the instructions each one follows.

STEP 04

Run

An action agent refreshes it on schedule or on demand. It can only submit fresh values — it can never change the design or create schedules.

STEP 05

Share

Send the link. Viewers see the latest page, can press the buttons you enabled, and nothing else.

What it watches

Four things security teams need to see continuously.

Continuous exposure monitoring

Scheduled scans of internal and external ranges show every open port, service and fingerprinted OS. Because a run remembers the previous one, the page flags what changed: a new open port, a new service, a newly exposed host.

Vulnerability posture at a glance

Products and versions found by scans are matched to known CVEs. The page shows severity counts, the most exposed hosts and the findings that need attention first.

Code and supply-chain risk

Dependency scans find known-vulnerable packages; static code scans find risky code and leaked secrets — across repositories, with new findings flagged run over run.

Configuration and hardening compliance

Agents check servers, network devices and cloud or Microsoft 365 settings against your baseline and show exactly which checks pass and which fail.

Why it matters

Investigated, actionable, and on the record.

  • Findings investigated, not just listedThe action agent can investigate each finding with read-only checks and show the evidence, the likely cause and a proposed fix. Remediation happens only when you define a button for it, with explicit instructions.
  • Security actions one click awayButtons such as "Rescan now", "Re-verify this finding" or "Collect evidence" — each following instructions you wrote.
  • Audit-ready evidenceEvery run keeps its full record of what was checked, every command and every result — evidence for audits and incident reviews.
  • Built and changed in plain languageNo BI tool, no front-end development. Describe the change; the design agent makes it.
  • Runs where the data isOn your own appliance, on your internal networks. Vulnerability definitions and code rule packs are stored locally, so it works in air-gapped environments.
  • Cost controlA stronger model designs the page; a cheaper, faster model handles the routine refreshes.

Technical summary

How it's built.

Two roles

The design agent works in a chat-based studio. It collects a checklist of required information, defines the data contract — named value "slots" — and writes the action instructions. It must pass a validation run against the real environment before the page can be built.

The action agent follows those instructions with only the tools it has been given, and can only submit values into the slots. It can never change the page's design or create schedules. Runs can be done by a single agent or an agent team, supervisor or sequential.

The page

  • Free-form HTML, CSS and JavaScript written by the design agent, up to 10 MB, with approved chart and UI libraries allowed.
  • Runs in a sandboxed frame that allows scripts only — it has no access to DIRVA AI or the viewer's session.
  • Reads the latest values through a small bridge; open pages check for new values on a set interval (15 seconds by default). Values can total up to 50 MB per dashboard.

Runs

  • Started by schedules — any interval, cron or one-time; time-zone aware; no drift across restarts — or by action buttons, in the studio or on the shared page.
  • Unattended: each agent's own tool permissions and approval settings apply, and question and password prompts are removed.
  • A missing login stops the run straight away and the design agent asks for it. Logins given during design are saved on the dashboard for its runs.

Scale and reliability

  • Runs go through a PostgreSQL work queue shared by all of the appliance's worker processes.
  • Each dashboard runs one at a time: a scheduled tick or button press that arrives while a run is in progress is skipped.

Visibility

  • Every run keeps its full transcript — each AI turn and tool call — and can be watched live or stopped.
  • Run history retention is configurable; the default keeps the newest 200 runs, up to 30 days.

Access and sharing

  • Owners and chosen admin groups can edit; platform admins see every dashboard, and ownership can be transferred.
  • Sharing is optional and view-only. A share link always shows the latest page — no drafts or versions. Viewers can't chat, but they can press the enabled action buttons.

Get started

See a dashboard built live.

Bring a question you'd want answered continuously — we'll build the page with you in the demo.

Request a DemoContact DIRVA