Concepts
Findings
A finding is a confirmed security issue with its evidence. Kelvar records findings as they are confirmed and keeps them on the Findings screen, so results do not live only in a chat report.
#Where findings appear
Dashboard opens on the Findings screen. It lists every finding that agents have sent, sorted by severity. You do not need to ask an agent to "save" a finding. When an audit finishes, each confirmed finding is already recorded.
#What a finding contains
| Field | Meaning |
|---|---|
severity | critical, high, medium, low or info. |
category | dependency, workflow, secret, code, config, iam, network, storage or other. |
title | A short description of the issue. |
repository / target | The repository, cloud account, or server host the issue was found on. |
file / resource and line | The exact file or cloud resource ARN/ID and optional line number. |
advisoryIds | Advisory identifiers such as CVE numbers. |
evidence | What the agent read that supports the finding. |
remediation | The change that would fix it. |
| First seen, last seen | When the finding was first and most recently confirmed. |
| Run IDs | The tasks that confirmed it. |
#How repeat audits merge
Kelvar audits on a schedule, so the same issue is confirmed many times. Findings are merged by repository/target, file/resource, category and advisory. A repeat audit updates the last-seen time and adds its run to the existing row. It does not create a duplicate.
#Coverage strip & scheduled scans
The Findings screen includes a real-time Coverage Strip for all connected sources (GitHub, AWS, Google Cloud, Azure, Linux servers). Each source displays its active status, scheduled scan cadence, severity breakdown, and immediate Scan now or Pause / Resume actions.
#Triage workflow
Findings can be triaged directly in the dashboard:
- Dismiss (False Positive): Records a reason and hides or marks the issue.
- Accept Risk: Records operational justification and accepted risk.
- Mark Resolved: Records verification that the issue has been remediated.
Every triage decision records a security.finding.triage artifact in the append-only, hash-chained ledger.
#What an agent sends
An agent records a finding by sending a security.finding artifact to the system_security_findings interface. The payload is validated when it is read. A malformed finding is not dropped silently. It is listed as rejected with the reason, so a bad payload is visible and fixable.
#Acting on a finding
Each finding has three actions. Each opens a task with a specific agent.
| Action | Agent | Instruction given |
|---|---|---|
| Remediate | Security Patch & Remediation Engineer | Prepare the smallest verified patch in an isolated worktree and report the exact diff. Do not push, merge or open pull requests. |
| Verify exploitability | Zero-Click Rapid Defender | Confirm from the source whether the finding is reachable and exploitable, and say what evidence supports or refutes it. |
| Escalate to SOC | 24/7 Autonomous SOC Sentinel | Correlate with other recent signals, judge whether it indicates an active incident, and state the decision with reasons. |
Remediation never publishes anything on its own. To let Kelvar open pull requests, connect the separate write-back application. See Connect GitHub.
#Scanner findings
The command-line scanner reports findings in a simpler shape, with a check, severity, path, line and message. They are described in Scanner checks. Scanner findings are deterministic. Agent findings are confirmed by a model reading the code, and carry evidence.