Findings

A finding is the unit of work output that matters. Your agents can do recon, triage, exploitation, or monitoring. In every case, the durable record is a list of findings. Each finding states what the agent discovered, where, with what evidence, and how serious it is.

This page covers the full finding lifecycle: how an agent submits one, what appears in the dashboard, how your team triages, and how to export.

What a finding contains

Every finding has the same shape:

Field	Required	Notes
Title	yes	One-line description (e.g. "Exposed admin endpoint /admin/console").
Severity	yes	critical, high, medium, low, info. Drives sorting and SLA timers.
Target reference	yes	The asset the finding applies to. Usually populated automatically from the mission's target.
Description	yes	Markdown. The full write-up, what was found, why it matters, suggested remediation.
Evidence	recommended	Structured payload (request/response excerpts, config snippets, traces). Stored verbatim.
Tags	optional	Free-form labels, e.g. pci, internal, bug-bounty. Used for filtering.
CWE / CVE references	optional	Standard identifiers Gibson links to upstream advisories.
Confidence	optional	confirmed, likely, tentative. Triage uses this to prioritize.

Submit a finding from an agent

err := h.SubmitFinding(ctx, agent.Finding{
    Title:       "Exposed admin endpoint /admin/console",
    Severity:    agent.SeverityHigh,
    TargetRef:   h.Target().Id,
    Description: "The /admin/console route is reachable without authentication...",
    Evidence: agent.Evidence{
        Request:  rawReq,
        Response: rawResp,
    },
    Tags: []string{"recon", "auth-bypass"},
})

That is all. Gibson then:

1. Persists the finding scoped to the current mission.
2. Links it to your agent execution and the mission run (so the dashboard can show provenance).
3. Stores it in the knowledge graph as a :finding node, linked through AFFECTS to the host, service, or endpoint it targets.
4. Emits a finding.submitted event on the mission's stream.
5. Notifies any configured alerting destinations (Slack, email, webhook) based on the severity policy in your tenant's settings.

You can also call h.GetFindings(ctx, ...) from inside an agent. This call retrieves findings already submitted in the current mission. It is useful for triage agents that aggregate or de-duplicate.

Triage in the dashboard

Open Missions → [your mission] → Findings, or the global app.zeroroot.ai/dashboard/findings page for a tenant-wide view.

Each finding row shows:

• title, severity, confidence
• target it affects
• mission and agent that produced it
• timestamp and any tags

Click a row to open the detail page, where you can:

Action	What it does
Change status	New → Triaging → Confirmed → Remediated → Closed (or False positive). The state machine drives SLAs.
Reassign	Move the finding to a teammate or rotation.
Add a comment	Threaded discussion. Comments are part of the audit log.
Link related findings	Group duplicates or cluster a campaign.
Attach evidence	Add screenshots, log excerpts, or reproduction steps post-hoc.
Replay the producing mission	Jump to the mission detail page and replay from the checkpoint just before this finding was submitted. Use it to verify a fix or to try a different prompt.

SLA and severity

Severity drives default SLA timers visible on the finding detail page:

Severity	Default SLA
critical	24 hours
high	7 days
medium	30 days
low	90 days
info	no SLA

Tenant admins can override these defaults under Settings → Findings policy.

Filter and search

The findings list supports filters by:

• severity, status, confidence
• target, mission, agent
• tag and CWE/CVE
• date range
• free-text search across title and description

Save a filter as a named view (e.g. "Open critical web findings") and pin it to your sidebar.

Export

Click Export on the findings list to download the current filtered view. There are three formats:

Format	Use it for
JSON	Programmatic intake into a SIEM / GRC tool.
CSV	Spreadsheet review.
SARIF	GitHub / IDE integration. PR comment format.

Exports respect your filter. You get exactly the rows you see. JSON and SARIF include evidence payloads. CSV truncates evidence to a summary.

Webhooks and integrations

Configure outbound destinations under Settings → Integrations:

Destination	Trigger
Slack	Post a message on every finding above a chosen severity.
Email	Send a digest (real-time, hourly, or daily) to a distribution list.
PagerDuty	Open an incident on critical findings.
Generic webhook	POST a JSON payload, same shape as the JSON export, one finding per request.
Jira / Linear / GitHub Issues	Auto-create an issue with title + severity + a link back to the finding.

Each destination has its own filter. You only get the noise you asked for.

Relationship to the knowledge graph

Every finding becomes a :finding node in your tenant's knowledge graph (see Knowledge graph), linked to:

• the target asset it affects (:host, :service, :endpoint, …)
• the agent execution that produced it (provenance)
• any attack patterns or techniques it instantiates
• similar prior findings via embedding similarity

These links let a future triage agent call FindSimilarFindings(...) and learn from history. You do not wire anything yourself.

Related

• Your First Agent: where SubmitFinding fits in agent code.
• Missions: finding.submitted in the event stream.
• Knowledge graph: how Gibson links findings to hosts, services, and attack patterns.
• Taxonomy: the standard finding categories that ship with Gibson.
• Ontology: map custom finding categories into CWE, SOC 2, MITRE ATT&CK, and other industry vocab.