A candidate finding is a potential vulnerability identified by a tool, researcher, or model that has not yet been confirmed as exploitable. Security teams should treat it as evidence to validate, not as a finished defect, because context and runtime conditions determine whether it is real.
Expanded Definition
A candidate finding is an unverified security signal: a tool, researcher, or model has identified something that may be a weakness, but there is not yet enough evidence to confirm exploitability. In NHI and agentic AI programs, that distinction matters because automated analysis can flag everything from exposed secrets to suspicious permission paths, yet runtime context determines whether the issue is material. Candidate findings often appear in scanning, code review, red teaming, and AI-assisted detection pipelines, where the output is intentionally broader than the final vulnerability set.
Definitions vary across vendors and workflows. Some teams treat a candidate finding as any preliminary alert, while others reserve the term for items that have passed an initial triage step but still require validation. That means the operational meaning should be documented in the review process, not assumed from the label alone. For governance alignment, compare candidate findings against the triage expectations in the NIST Cybersecurity Framework 2.0 and the control objectives described in the Ultimate Guide to NHIs.
The most common misapplication is treating every candidate finding as a confirmed defect, which occurs when teams skip validation and feed unverified alerts directly into remediation queues.
Examples and Use Cases
Implementing candidate finding handling rigorously often introduces triage overhead, requiring organisations to balance faster detection against the cost of validation work.
- A scanner flags an API key in a CI/CD log. The item remains a candidate finding until the team confirms whether the key is active, scoped, and reachable from the reported environment.
- An LLM-assisted code review suggests a secret exposure in a service account configuration. Reviewers validate whether the reference is a test artifact, a dead credential, or a live secret before opening a defect.
- A cloud posture tool reports excessive permissions on an NHI. The candidate finding becomes actionable only after checking the actual runtime path, trust boundary, and blast radius.
- A researcher submits a potential SSRF path in an agent toolchain. Security teams reproduce the condition in a controlled environment before classifying it as exploitable or dismissing it as non-impactful.
- An internal scan identifies a certificate that appears expired. The team verifies whether the workload still trusts it, whether rotation already occurred, and whether any dependent services are failing.
These workflows align with the validation discipline implied by Ultimate Guide to NHIs, especially where secrets, service accounts, and exposure paths are involved.
Why It Matters in NHI Security
Candidate findings matter because NHI environments create a large volume of signals that can look urgent before they are proven. That is especially true when secrets, service accounts, and API keys are spread across code, CI/CD tools, and cloud control planes. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows why weak triage is not a harmless process issue. If validation is delayed, real exposure can be buried under noise; if validation is skipped, teams waste effort on false positives and miss the genuinely exploitable path. The same discipline supports stronger governance under the NIST Cybersecurity Framework 2.0, where detection must lead to reliable assessment and response.
Candidate findings are also important because NHI compromise is often only visible after suspicious use, unexpected privilege escalation, or a failed rotation attempt exposes the weakness. Organisations typically encounter the real operational impact only after a breach investigation, at which point candidate finding handling becomes unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers detection and validation of NHI weaknesses before they become confirmed issues. |
| NIST CSF 2.0 | DE.CM | Detection events must be assessed to distinguish real incidents from preliminary alerts. |
| NIST AI RMF | MAP | AI-generated findings need context and evaluation before they are trusted as actionable. |
| OWASP Agentic AI Top 10 | A-02 | Agentic outputs can surface unverified risks that need human verification. |
| CSA MAESTRO | GOV-03 | Governance requires a review process for preliminary security signals from autonomous systems. |
Triage candidate findings quickly, then validate impact and exploitability before opening remediation work.
Related resources from NHI Mgmt Group
- What is the difference between finding an AI agent and governing it?
- What is the difference between finding risky access and preventing risky access?
- What should teams do first after finding over-privileged cloud identities?
- Who should own remediation when an NHI finding affects production services?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
