Findings & Evidence

A finding is a confirmed vulnerability discovered during an audit. Golem AI’s defining principle: Golem only emits findings on confirmed compromise or exposure — not theoretical issues, not “potential” weaknesses, not unverified scanner output.

Finding structure

Every finding includes:

Field	Description
`id`	Unique identifier within the audit
`title`	Plain-English summary
`description`	Detailed explanation of what’s wrong and why it matters
`severity`	Critical / High / Medium / Low / Informational
`class`	`exploit` (confirmed RCE/auth bypass/etc.), `exposure` (sensitive data visible), `misconfiguration`, or `coverage` (documented gap)
`source`	`agent` (found by Golem) or `baseline` (found by deterministic scanner before the agent ran)
`category`	Class of issue (e.g., `auth_bypass`, `sqli`, `exposed_credential`)
`cwe`	CWE identifier (e.g. `CWE-89`)
`cve`	CVE identifier if applicable, enriched with CVSS and CISA KEV status
`evidence`	Structured evidence object — see below
`recommendation`	Specific remediation steps
`discoveredAt`	Timestamp

Severity levels

Severity	Score impact	Examples
Critical	−30 pts	Confirmed RCE, authentication bypass, exposed admin panel without auth, leaked production credentials
High	−15 pts	SQLi with data extraction, stored XSS, privilege escalation, exposed sensitive PII
Medium	−8 pts	Reflected XSS, IDOR with limited impact, CSRF on state-changing endpoints, weak TLS
Low	−3 pts	Information disclosure, missing security headers, verbose errors, version disclosure
Informational	0	Observed configuration choices, hardening opportunities, no impact

See Security Score for how these compose into the letter grade.

How findings are validated

Golem AI enforces a three-layer validation pipeline before any finding is accepted into an audit: Layer 1 — Submission gate (real-time) Golem submits findings through a report_finding() tool call, never by emitting text. At submission time, the orchestration layer validates:

The cited command ID (evidence.cmd_id) must exist in the execution ledger for this engagement
That command must have exited successfully and produced output — not just run
Any stack-specific claim (e.g. “Jinja2 SSTI”, “Firebase misconfiguration”) requires that stack to have been fingerprinted from actual recon output earlier in the engagement

Findings that fail this check return [finding_rejected] to the agent and are silently dropped. Layer 2 — Deduplication Before entering the pending queue, each finding is checked against all existing findings by stable ID and by CWE × affected URL. This prevents the agent from re-reporting a vulnerability already caught by the baseline scanner, even if the title phrasing differs. Layer 3 — Post-hoc verification Before findings are written to the database, a verifier cross-checks each critical/high finding’s claimed response against the actual stdout of the cited command. Read-only curl commands are replayed in the sandbox and the live response is compared to what the agent claimed. A finding that fails any layer is dropped, not downgraded.

Evidence

Evidence is what separates confirmed findings from scanner output. Every finding includes the raw artifact that proves the vulnerability exists.

What evidence looks like

For an authentication bypass, evidence might be:

$ curl -i https://admin.acme.example.com/api/users \
    -H 'X-Forwarded-For: 127.0.0.1'

HTTP/2 200
content-type: application/json

[
  {"id": 1, "email": "ceo@acme.example.com", "role": "admin"},
  {"id": 2, "email": "cfo@acme.example.com", "role": "admin"},
  ...
]

For a SQL injection finding:

sqlmap -u 'https://acme.example.com/search?q=foo' --batch --dump

Database: app_production
Table: users
[247 entries]
+----+----------------------+-----------+
| id | email                | password  |
+----+----------------------+-----------+
| 1  | alice@acme.com       | $2b$10... |
...

This is what auditors, customers, and engineering leads will see in the PDF report. There’s no ambiguity.

Browsing findings

From the dashboard

Per audit — open an audit to see all its findings, filterable by severity
Across the workspace — the Findings view aggregates every finding across all audits in the workspace
Across workspaces — the global findings page (top-level Findings) aggregates everything

From the API

# All findings for an audit
curl https://api.usegolem.ai/api/workspaces/{workspaceId}/audits/{auditId} \
  -H "Authorization: Bearer $GOLEM_API_KEY"

# Just the structured report
curl https://api.usegolem.ai/api/workspaces/{workspaceId}/audits/{auditId}/report \
  -H "Authorization: Bearer $GOLEM_API_KEY"

Verifying remediation

To verify a finding is remediated:

Apply the fix
Re-run an audit against the same target (typically Shallow is enough)
Confirm the finding is no longer present
Compare the asciinema recordings before/after for full transparency

Next steps

Reports & Recordings

PDF export and full session replay.

Security Score

How findings compose into a letter grade.

Getting Started

Audits

How It Works

Platform

Billing

Findings & Evidence

Findings & Evidence

Finding structure

Severity levels

How findings are validated

Evidence

What evidence looks like

Browsing findings

From the dashboard

From the API

Verifying remediation

Next steps

Reports & Recordings

Security Score

​Findings & Evidence

​Finding structure

​Severity levels

​How findings are validated

​Evidence

​What evidence looks like

​Browsing findings

​From the dashboard

​From the API

​Verifying remediation

​Next steps

Reports & Recordings

Security Score

Findings & Evidence

Finding structure

Severity levels

How findings are validated

Evidence

What evidence looks like

Browsing findings

From the dashboard

From the API

Verifying remediation

Next steps