Home / Threat library
Threat library for NHI misuse
Quantlyx Security does not stop at where your non-human identities are. It shows what those NHIs are doing, and flags misuse early: off-purpose use, standing access after revoke, and a change that requested one action while runtime did another. The threat library scores those threads as SOC-ready signals and routes a ranked worklist to the SIEM, the service desk, and change management, so the practitioner acts before the misuse spreads.

What the NHI is doing, not only where it is
An inventory tells you a service account, release bot or coding agent exists. The threat library joins the grant to later use, so the question becomes whether that use is the work the identity was approved for.
If and when it is misused
Misuse is the finding, and it is flagged early, as it happens, rather than after a quarterly review. Each thread is scored as a SOC-ready signal with its evidence attached.
Change requested ABC. Runtime did DEF.
The change record says what was approved. The pipeline and the runtime show what ran. Quantlyx shows every place the two disagree, while the identity is still in use. See change requested versus what ran.
Standing access after revoke
Revoked in one console, still live in another. The joined view is the finding, and it is a named threat-library signal.
Off-purpose access
A valid grant used for something the ticket or certification never defined, by a person, a service account or an AI agent.
Orphaned service account
The owner left and the account still runs. An ownerless build or release identity that can still deploy is misuse, not a missing inventory row.
From the library to the SIEM, service desk, and change platform
Each scored thread becomes a line on a ranked worklist and is routed to the SIEM, the service desk and change management, so the practitioner acts on the misuse before it spreads. What happens after the signal is identity threat remediation: contain the session, rotate the credential, close on proof from the source system. Quantlyx ranks and routes; your existing governance and access platforms carry out the change, and QuantQFix acts only on what a person approves.
What the threat library does
Access-pattern detection
Is this grant being used as a threat would use it: by a person, a service account, or an AI identity.
Signals ready for the desk
Named patterns, evidence attached. The operations team is not asked to read the catalogue.
Ranked worklist
Recertify, rotate, recover, assign an owner. Highest-risk lines first.
Non-human identities
Service accounts, release bots and coding agents on the same register as people. Owner gone, grant live is a named library entry.
Entitlement risk
The object is the entitlement, not the session. Rank by risk, attach a definition, route a named action.
Needle in the haystack
Most identity estates produce more entitlements than any team can read. Only the line that looks like misuse pages the desk.
Other platforms show you the entitlement. Quantlyx shows you when the entitlement is being used as a threat would use it.
Named patterns, and the evidence each one shows
Each pattern is a named entry the operations team can act on. The evidence travels with the finding.
| Pattern | What it joins | Evidence shown | Where it lands |
|---|---|---|---|
| Standing access after revoke | The revoke or leaver event with later use of the same entitlement | The revoke date next to the deployment or use that came after it, and the token that was never rotated | Ranked worklist, action: rotate token |
| Off-purpose use of a valid grant | The grant's stated purpose (the ticket or certification) with what it was used for | The use that falls outside that purpose, by a person, a service account or an AI identity | Ranked worklist, action: recertify |
| Hour, region and asset together | The entitlement with when, from where and which asset it touched | An HR entitlement used from another country at 03:00 | Ranked worklist, action: page the SOC |
| Orphaned service account | The owner's departure with the account that still runs | Owner gone, grant live: an ownerless build or release identity that can still deploy | Ranked worklist, action: assign an owner |
| Change approved for a person, made by a bot | The change approval with who and what actually committed and merged | A coding assistant authored the commit under a credential that traces back to a named human | Ranked worklist, routed to the owner |
| Pipeline identities nobody enrolled | Build and deploy identities with the certification record | Identities holding repository write and deployment credentials that were never certified, used daily | Ranked worklist, routed to the owner |
| Break-glass release used as the normal release | The emergency path with the incident record | Repeated use by the same team or automation, with no matching incident behind it | Ranked worklist, routed to the owner |
| Change requested one action, runtime did another | The change record with what was committed, built, deployed and run | Every disagreement as a line with the evidence attached, while the identity can still be stopped | Ranked worklist, routed to the owner |
Ordinary automation versus the line that pages the desk
Automation is supposed to be busy, so being busy is not the finding. The library compares what each identity was approved to do with what it did, who owns it, and whether the change record matches what ran.
A release bot that deploys every day under a live approval is ordinary. The same bot deploying after its entitlement was revoked, from a new region, or under a credential that traces back to a person who did not make the change, is the line that pages the desk.
How do you know what a non-human identity is doing, not only where it is?
Quantlyx joins the grant to later use. Location in an inventory is not the finding. Misuse is the finding: off-purpose use, use after revoke, and use that does not match the change that was approved.
How do you catch an NHI being misused early?
The threat library scores the thread as a SOC-ready signal and sends it to the SIEM, the service desk, and change management. The practitioner acts on the misuse instead of waiting for a quarterly recertification.
How would you know the change requested ABC but runtime did DEF?
Quantlyx reads the change record and what was committed, built, deployed, and run. Every disagreement is a line on the worklist, with the evidence attached, while the identity can still be stopped.
How do you detect a service account used after it was revoked?
Standing access after revoke is a threat-library signal. Revoked in one console, still live in another. The joined view is the finding.
What about an NHI or AI agent with no owner still deploying?
AI agent identity security sits on the same register. An ownerless build or release identity that can still deploy is off-purpose access.
Is this another NHI inventory or an ITDR platform?
No. An inventory lists where identities are. An ITDR platform implies token theft and Golden SAML. This is grant versus use, scored as a SOC signal, with IGA still the system of record.
Three signals, walked as the needle
Off-purpose use of a valid grant
Service accounts and AI identities exist for a reason. The library flags when that work is used for something the ticket or certification never defined.
Hour, region and asset together
An HR entitlement used from another country at 03:00 is not “access granted.” It is a needle the library is built to lift out of the haystack.
Revoked on the record, still live
Owner left. Token not rotated. Change ticket closed and the account reused. Each pattern is a named entry the operations team can act on.
How a compromised actor moves through your lifecycle
A credential belonging to an automation is taken, and every stage after that looks legitimate because each system sees only its own half of the story.
plan
Agent token issued for a routine task.
Approval record onlycode
Token used to author and merge a change.
Needs both registersbuild
Artefact signed by the build identity.
Lifecycle onlydeploy
Promoted to production out of window.
Needs both registersrun
Credential still valid after revocation.
Needs both registersFour findings neither register can raise alone
These are the questions that require the approval record and the lifecycle event in the same view to be answerable at all.
The change was approved for a person and made by a bot
A coding assistant authored the commit and merged it under a credential that traces back to a named human. The approval reads clean, the authorship does not.
record: approved for a named engineer · source control: authored by an automation identity
Pipeline identities nobody enrolled
Build identities, release bots and agent runners that hold repository write access and deployment credentials, use them daily, and were never certified or assigned an owner.
governance: absent · pipeline: active every day
Access revoked in the record, still deploying in production
The entitlement was closed at the leaver or recertification step. The token it depended on was never rotated, so the pipeline is still shipping.
record: revoked · deployment log: successful, last week
Break-glass release used as the normal release
An emergency path that skips review, taken repeatedly by the same team or automation, with no matching incident behind it.
record: emergency only · release log: recurring, no incident reference
What we cover, and what we do not
Against the Open Worldwide Application Security Project Top Ten for Agentic Applications, 2026 edition. We publish the whole map, because a governance layer that claims ten out of ten is not one you should trust with an audit.
Hover, tap or tab to a tile to see what the entry is and where Quantlyx stands.
Addressed directly
Quantlyx is the control. The finding, the evidence and the ownership trail come from the reconciliation itself.
Addressed in part
Quantlyx supplies the identity and lifecycle half of the picture. Something else in your stack supplies the rest.
Not addressed
Outside the reach of a read-only reconciliation layer. We will tell you which tooling does cover them.
Entry names follow the Open Worldwide Application Security Project GenAI Security Project list released in December 2025; descriptions are our summaries. The mapping with supporting evidence goes out with the executive briefing. Ask for it on the booking page.
ID entitlement. Rank by risk. Remediate.
Start with a two-week, read-only pilot against one lifecycle path. If nothing turns up, you keep a clean report.