Discovery screen

Discovery is a workspace for reviewing approved private-network, TLS, and file-exposure checks. It produces signals and redacted evidence for an operator to review; it is not a vulnerability scanner, credential-testing tool, asset inventory, or automatic cleanup service.

Access, role, and license boundary

Owner, Admin, and Auditor can open Discovery when the license includes the Discovery feature. Admin and Auditor have a read-only view of policies, runs, findings, suppressions, and import state. User cannot open the screen.

Every change requires the Owner, the Discovery feature, and a writable license. This includes saving a scan, Preview or Run, stopping, restarting, or deleting a run log, reviewing or suppressing findings, preparing import, and completing import. Import also requires an unlocked active vault where the Owner has Editor or Manager access.

The workspace refreshes automatically while open. Placeholder rows appear while loading; if loading fails, an error panel appears.

Three-step workflow

1. Run — compose and save approved scope, select checks, record a Preview, or perform a Run.
2. Findings — filter redacted signals, inspect evidence, and make review decisions.
3. Import — optionally add a narrow class of reviewed file findings to the active vault.

A network surface, certificate issue, or weak file signal can remain an operator finding without becoming a vault record.

Run: build an approved scan

Select checks

Only selected and available checks run:

Quick choices select all available checks, Files only, or Network + SSL/TLS. Network and file checks run together, so a failure in either one fails the whole run.

Private-network scope

Network scope accepts individual private (RFC 1918) IPv4 addresses, CIDR blocks, or explicit IPv4 ranges. Public addresses, host names, IPv6, loopback, and link-local targets are not accepted. The total limit is 512 hosts, and an explicit range must stay inside one /24. A scope containing any rejected entry cannot be saved.

The target preview lists accepted addresses, shows rejected entries, and summarizes long lists. It only previews the scope; it does not test reachability.

Port plans offer common low-noise sets: Premium default, Web login, Windows identity, and Narrow TLS. A policy accepts at most 32 ports. The default set is 443, 8443, 9443, 636, 3269, 5986, 80, 8080.

Network checks create real traffic: TCP connections, TLS handshakes, and limited HTTP/HTTPS requests. A small part of each web page can be read to recognize login or AD CS pages, and a few login links on the same site can be followed. No username, password, login form, exploit, brute force, or password spray is ever sent.

TLS checks read certificate details even when the certificate is invalid or untrusted. A certificate finding is risk evidence; it does not prove that a trusted TLS connection succeeded.

File scope and presets

Preset groups are resolved on the VaultPilot server:

• Windows folders: Desktop, Documents, Downloads, OneDrive, Public Desktop, and Public Documents.
• Server applications: IIS configuration, site and log locations, and Nginx or Apache configuration paths.
• DevOps and admin: eligible .ssh, .kube, .docker, .aws, Azure, and gcloud profile folders.

Presets can cover every local Windows profile on the server. What can actually be read depends on the account the VaultPilot service runs as. A missing or unreadable preset path yields no files.

Additional scope accepts approved absolute drive paths or normal UNC paths. A policy can hold at most 32 paths. Drive roots, relative or device paths, most Windows system paths, VaultPilot and legacy PassMan data folders, symbolic links, generated folders and files, unsupported extensions, unreadable entries, and oversized files are skipped or rejected.

A policy allows at most 80 file extensions. The default maximum file size is 5 MB; the upper limit is 25 MB. Timeout is 250–15,000 ms and concurrency is 1–16.

File checks can briefly read supported text, configuration, scripts, VPN/RDP, registry, Terraform, package-manager credential files, certificate and key files, and supported Office/Excel content in server memory. Discovery keeps only the detector, masked path, hashes, reasons, and a redacted preview, never the secret value itself. Source files are never changed, moved, quarantined, cleaned, or deleted.

Explicit approval and policy behavior

Network scope requires I am authorized to scan these private targets. File scope requires These file paths are approved for read-only scanning. Editing either scope clears its approval. A scan can be saved only with valid network scope, approved file scope, or both.

Save scan always creates a new policy; the screen has no edit or delete action for saved policies. Clearing Scan enabled creates a Disabled policy. Run is disabled for it; Preview can still look available, but the server refuses both Preview and Run for a Disabled policy.

Preview, Run, and job controls

Preview and Run differ:

• Preview records an immediately completed preview job and an audit entry. It sends no network traffic, reads no files, and creates no findings.
• Run performs the selected checks. It can take several minutes, and the screen shows progress while it runs.

Only one job may be active per policy. Job states are Queued, Running, Cancellation requested, Completed, Cancelled, and Failed. Progress shows targets scanned, files scanned, findings processed, and the latest update.

Stop records a cancellation request. Cancellation is not immediate: the policy stays active and cannot start another run until the scan confirms it stopped. Delete is available only for a finished job after confirmation; it deletes the run log but keeps its findings. Restart uses the saved policy and the checks currently selected for it, not a frozen copy of the original run.

The process-log panel shows the most recent jobs. The expanded run history lists all of them. After a server restart, an unfinished job can later appear as interrupted or cancelled.

The findings count of a run is the number of signals it processed; it is not guaranteed to be a count of brand-new findings.

Findings: review redacted signals

The Findings view starts with High-confidence + Open findings. Restore default view returns to that filter, not to all findings. Search and advanced filters cover confidence, status, severity, source kind, candidate type, asset identity, reasons, masked path, and hashes.

The first page shows the newest findings. Load more findings loads older ones. Filters, bulk selection, review counts, and Import work only on findings already loaded. Selections outside the current filter stay selected until cleared.

The table and detail drawer show severity, confidence, candidate type, asset identity, redacted preview, detector, reasons, status, short evidence hash, optional masked path and path hash, and updated time. Even masked evidence can identify internal systems; keep it private unless deliberately sanitized.

Finding lifecycle

Ignore closes only the current finding. Suppress creates a lasting rule so future matching signals are stored as Suppressed. Suppression happens immediately and asks for no reason, so the rule normally shows No note. Reopening a suppressed finding does not remove the rule, and this screen has no control to delete suppression rules.

Finding actions show no confirmation dialog. Bulk Start review affects only visible, selected Open findings. The screen does not link a finding to an existing vault record.

A completed file Run can automatically mark Open, In review, or Ready-to-import file findings as Remediated when the evidence is gone from paths that were scanned successfully. Ignored, Suppressed, and Imported findings are not changed by this.

Import: short-lived material handoff

Only a narrow kind of file finding can be imported. It must be Ready to import, come from a file check, point to a known location, and be classified as Password, API key, Certificate, or Credential. Network surfaces, TLS findings, notes, and general file evidence are signals only.

Import candidates come from loaded findings. Load older findings first when an expected candidate is missing.

For each import:

1. VaultPilot reads the approved source again and checks that it still matches the evidence.
2. The value is handed to your browser only, for a short time.
3. The browser builds the record and encrypts it with the active vault key.
4. The server checks the evidence, your vault access, and the record type, then stores the encrypted item and marks the finding Imported.

If the source changed, moved, disappeared, or no longer matches the evidence, import stops and the finding must be reviewed again. The server never keeps the plaintext value.

Selected imports run one by one, not as a single step. If a later item fails, earlier imports stay. Import does not clean the source; Mark remediated changes only the finding’s state.

Audit trail

Discovery records audit entries for policy save, Preview and Run start, run cancellation and log deletion, finding review, Ignore and Suppress, import preparation and the source read, the vault import, import completion, and manual remediation. Deleting a job log does not delete its findings. Automatic remediation after a completed file Run is part of that Run and does not create a separate manual-remediation entry for every finding.

Screen states

Before you act

• Obtain explicit authorization for every private target, UNC share, drive path, and profile area a preset covers.
• Confirm the VaultPilot service account has only the intended read access; presets do not grant file permissions.
• Choose the smallest target, port, path, extension, size, timeout, and concurrency scope that answers the question.
• Treat Preview as a recorded plan only; use Run when real evidence is needed.
• HTTP checks create web traffic and file checks briefly read source content.
• Review status, confidence, detector, masked path, reasons, and ownership before Ignore, Suppress, or Import.
• Before import, confirm the active vault, write role, record owner, destination category, and plan for cleaning the source.

Safe evidence

• Safe to share: scan kind, policy and job state, approximate target, file, and finding counts, severity, confidence, candidate type, detector ID, broad time window, the redacted error, and a deliberately redacted path or host.
• Keep private: real IP, CIDR and port lists, host names, UNC or local paths, usernames, full asset identity, exact times, raw or linkable previews, source files, source values, private key or certificate material, vault name, databases, backups, exports, and imported record content.
• Evidence and path hashes can still link systems across reports. Share shortened or fully masked values unless support asks for an exact comparison.
• Never attach a source file or recreate the discovered value in a support email. Send only the redacted finding details to support@vaultpilot.io.

When to stop and escalate

Stop when scope ownership is unclear, a public or unexpected target appears, presets reach outside the approved area, file access is broader than intended, a run stays active without progress, cancellation is not confirmed, findings expose more context than expected, suppression hides an unexplained class of signals, material changes during import, import partly succeeds, or a remediated decision conflicts with audit evidence. Email support@vaultpilot.io with role, general state, scan kind, broad time window, shortened hashes, the redacted error, and last safe step, without real scope or secret material.

Operator notes

Discovery collects and reviews evidence; it proves neither compromise nor absence. A clean result covers only the selected checks, accepted scope, readable files, supported formats, limits, and time of that Run. Marking a finding Remediated does not change the source. Suppression is lasting and should be used only when future matching signals are meant to be hidden.

Related

• Discovery guide
• Discovery finding review KB
• Redacting support evidence
• Audit Log screen

Back to Documentation →