A prompt-based detector is a detection method defined in plain language rather than regex or manual model tuning. It uses examples and descriptions to identify matching entities or files, which helps security teams create controls for company-specific sensitive data without building rules from scratch.
Expanded Definition
A prompt-based detector is a plain-language detection pattern that describes what to find, rather than relying on a rigid regular expression or a hand-tuned classifier. In NHI security, it is used to flag sensitive entities, files, or artifacts by example-driven descriptions such as naming conventions, content cues, and contextual attributes. That makes it useful when teams need fast coverage for organisation-specific secrets, service accounts, or other NHI-related indicators that are hard to express in a single rule.
Definitions vary across vendors, because some tools treat prompt-based detection as a workflow for creating rules while others treat it as a model-assisted classification method. The practical distinction is that the prompt expresses the detection intent in human language, and the system translates that intent into matching logic. This sits between manual review and fully engineered detection, and it is often paired with governance controls such as secrets inventory and lifecycle oversight from the NHI Lifecycle Management Guide. For a broader control context, NIST’s NIST Cybersecurity Framework 2.0 reinforces the need to identify and protect sensitive assets consistently.
The most common misapplication is treating a prompt-based detector as if it were a fully deterministic rule, which occurs when teams expect perfect precision without testing against realistic false positives and misses.
Examples and Use Cases
Implementing prompt-based detection rigorously often introduces tuning overhead, requiring organisations to weigh faster rule creation against validation effort and false-positive management.
- Detecting API keys in source code by describing common formatting patterns, surrounding comments, and repository paths, then refining the prompt as new code patterns appear.
- Flagging cloud credentials in CI/CD logs by asking the detector to identify access tokens, bearer strings, or secret-like values that appear in build output.
- Finding service-account references in documentation or configuration files when naming conventions vary across teams and a fixed regex would miss edge cases.
- Screening file shares for NHI-related artifacts using examples from Top 10 NHI Issues to help guide what “sensitive” looks like in real environments.
- Aligning detector output with policy language from Ultimate Guide to NHIs — Key Challenges and Risks when the target material includes leaked secrets, exposed identifiers, or overprivileged credentials.
In practice, teams often use prompt-based detectors as a bridge between human knowledge and automated scanning, especially when the target pattern is known conceptually but not yet stable enough for a formal rule set. Security analysts can also use them to accelerate triage before converting high-value prompts into durable controls.
Why It Matters in NHI Security
Prompt-based detectors matter because NHI exposure is often messy, distributed, and poorly normalized across code, tickets, chat logs, and infrastructure files. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which makes rapid detection design more than a convenience. When teams can express detection intent clearly in plain language, they can cover emerging NHI threats faster than with brittle handcrafted patterns alone. That is especially relevant for secrets sprawl, shadow service accounts, and files that contain credentials outside approved vaults.
They are also useful for governance because they help operationalise what should be found, reviewed, and escalated, even when a formal data classification program is incomplete. However, prompt-based detectors still need measurement, review, and change control, because the wording of the prompt can shift results in ways that are not obvious to operators. This is where NHI security moves from theory into incident response and remediation.
Organisations typically encounter the need to formalise prompt-based detection only after a secrets leak, at which point the term becomes operationally 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 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret handling and detection of exposed NHI credentials. |
| NIST CSF 2.0 | DE.CM-1 | Monitoring for anomalous or sensitive artifacts aligns with continuous detection practices. |
Use prompt-based detectors to find likely secrets, then validate findings against NHI-02 review and response workflows.
Related resources from NHI Mgmt Group
- What is the difference between prompt-based control and runtime authorization for agents?
- Why do browser-based prompt injections create a bigger trust problem than email summaries?
- How should security teams govern AI agents that can change behaviour based on prompt context?
- What is the difference between prompt-based safety and hard runtime boundaries?
