Custom Detection

Expanded Definition

Custom detection is a purpose-built rule or analytic that flags activity unique to one environment, application, or threat model. In NHI and browser security, it goes beyond generic signatures by inspecting DOM events, request paths, headers, token use, or control violations that reflect how an organisation actually operates.

Unlike vendor-default detections, custom detection is tied to local business logic and therefore changes as the application, identity flows, or threat assumptions change. That makes it especially relevant where browser extensions, agentic workflows, or service-to-service access patterns create signals that standard controls miss. It also aligns with the broader monitoring and response concepts described in the NIST Cybersecurity Framework 2.0, although no single standard governs the exact shape of a custom detection rule yet.

The most common misapplication is treating a custom detection as a permanent one-off rule, which occurs when teams fail to maintain it after application changes, identity changes, or normal behaviour shifts.

Examples and Use Cases

Implementing custom detection rigorously often introduces maintenance overhead, requiring organisations to weigh faster abuse detection against the cost of tuning and false-positive review.

• A browser control watches for unexpected DOM mutation patterns that indicate credential scraping or prompt injection against an internal agent interface.
• A rule alerts when a service account sends requests with a valid token but an abnormal header sequence that suggests replay or automated misuse, a pattern often discussed in the Top 10 NHI Issues.
• A custom alert detects API calls from a trusted workload that suddenly begin accessing admin-only paths, helping teams identify privilege drift before broader compromise.
• A detector flags a browser session that loads a sensitive page and then exfiltrates data through an unexpected request flow, even if the traffic looks normal at a signature level.
• A security team creates a rule around key rotation abuse, where a token is used after the expected offboarding window documented in the NHI Lifecycle Management Guide.

These patterns are often built by combining internal telemetry with guidance from NIST Cybersecurity Framework 2.0 functions such as detect and respond.

Why It Matters in NHI Security

Custom detection matters because NHI abuse is frequently contextual: the same token, browser session, or agent action may be legitimate in one workflow and malicious in another. That is why broad controls alone are not enough. NHI Management Group data shows that only 5.7% of organisations have full visibility into their service accounts, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In that environment, detection that reflects local behaviour is often the difference between catching misuse early and missing it entirely.

For NHI security teams, custom detections help surface exposed secrets, abnormal rotation failures, and browser-based abuse that generic SIEM content may not recognise. They also support governance by tying alerts to specific owners, workflows, and control expectations instead of treating all identity events the same. The strongest programs review these rules alongside lifecycle changes and access reviews so detections remain aligned with operational reality. The most useful reference point is the point where routine monitoring fails and a live incident begins to reveal the gap.

Organisations typically encounter the need for custom detection only after a suspicious token use, browser abuse, or service account compromise bypasses default alerts, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When should organizations prioritize the detection of shadow AI agents?
• What are effective practices for operationalizing NHI threat detection?
• How do organisations reduce false positives in secret detection pipelines?
• When does regex-based secret detection become too unreliable for production use?