Non-human identity (NHI) is now the fastest-growing attack surface in most organizations, and AI agents are a large part of why: every agent runs on a fistful of machine credentials, each with its own scope and its own blind spots. When those credentials are abused, the investigation is fundamentally an identity problem — not “was this key used,” but “whose key is this really, and was it the agent doing its job or being turned against you?”
What agent credential abuse and NHI compromise look like
A non-human identity is any credential software authenticates with rather than a person: an API key, a cloud service principal or service account, an IAM role, an OAuth token, a client certificate. An AI agent typically holds several at once — one to its model provider, one or more per cloud, a token for each SaaS tool it can reach.
Agent credential abuse is the use of those identities to reach data or systems beyond their intended scope — ASI03 Identity and Privilege Abuse in the OWASP Top 10 for Agentic Applications. It shows up in two forms, and telling them apart drives the entire response:
- The agent misusing its own credentials. A hijacked or over-permissioned agent uses its legitimate keys to do something it should not — often the downstream effect of a prompt injection or excessive agency.
- Stolen credentials used by an outside actor. An attacker harvests the agent’s keys — from a repository, a log, a misconfigured secret — and authenticates as the agent, inheriting everything it can reach.
Why NHI investigations are hard
Account-centric IR playbooks assume a human you can pivot on. Non-human identities break that in several ways:
- One agent is many identities. The actor is fragmented across a model provider, two clouds, and several SaaS apps. There is no single “user” record — reconstructing who acted means stitching a sprawl of NHIs back into one entity.
- The identities are long-lived and over-scoped. Service accounts and keys rarely rotate and tend to accumulate permission over time, so an abused credential usually has a wide blast radius and a long tail.
- Abuse looks identical to use. A valid token used maliciously produces the same “success” entry as a valid token used correctly. There is no failed-auth signal to catch — only sequence, scope, and context separate the two.
- The evidence is scattered. The trail lives in the identity provider, each cloud’s audit log, each SaaS app, and the secrets manager, with no one source holding the whole picture.
The investigation, step by step
An NHI investigation is an exercise in attribution before analysis. It runs roughly in this order:
1. Enumerate the agent’s identities
Inventory every credential the agent holds or uses: model-provider keys, cloud service principals and roles, SaaS OAuth tokens, database users, certificates. You cannot investigate the abuse of an identity you did not know existed, and the unknown ones are where it hides.
2. Resolve the sprawl into one actor
Stitch those identities together so activity across every provider reads as one agent’s coherent story rather than four disconnected ones. This is the central move of NHI forensics — without it, the abuse is invisible, split across logs that each look individually unremarkable.
3. Establish the baseline, then reconstruct the window
Establish what this agent’s normal credential use looks like — which identities, which resources, which times and volumes — then pull the actions taken under each credential in the incident window and fuse them onto a single timeline. Abuse is a deviation from the baseline, visible only once the baseline is known.
4. Misuse or impersonation?
Decide whether the agent abused its own credentials or an outside actor used stolen ones. Impersonation tends to leave anomalies the agent’s own use would not — an unfamiliar source address, client, geography, or cadence. The answer changes everything downstream: one is an agency-and-hijack problem, the other a stolen-secret problem.
5. Find the origin
Trace the abuse back to its root: a prompt injection or poisoned memory that steered the agent, a key leaked in a repository or log, an over-broad role granted “temporarily,” a compromised CI token. Root cause is the difference between rotating one credential and closing the door the next abuse will walk through.
6. Establish blast radius and persistence
Determine what was reached, read, and moved under the abused identity — and crucially, what new access was created. Minting fresh credentials or grants is the classic persistence move; an investigation that stops at the originally abused key often misses the access the actor left behind.
7. Rate confidence, then report
A defensible account never overstates the evidence. Each finding carries its confidence and is labeled as attested by the logs or inferred from them, with genuine ambiguity stated plainly — reproducible, and backed by an intact chain of custody an examiner can defend line by line.
What to collect
NHI investigations live or die on identity evidence. The sources that matter most, and what each tells you:
| Source | What it tells you |
|---|---|
| Identity-provider / IdP logs | Token issuance, consent grants, and sign-ins across the agent’s identities |
| Cloud audit logs (CloudTrail, etc.) | Every action taken under each service principal or role |
| Secrets-manager access logs | Which identity read which secret, and when — often the leak point |
| SaaS audit logs | Actions per OAuth app or token across third-party tools |
| Model-provider request logs | Use of the agent’s API keys, tying activity back to the agent |
| Source & CI/CD logs | Where keys leak — repositories, pipeline output, build artifacts |
No single source attributes the abuse on its own; attribution emerges only once they are normalized and fused. More sources mean higher-confidence resolution, but the method degrades gracefully when only a few are available.
Common mistakes
- Treating each identity as a separate actor. Investigating the service principal, the API key, and the OAuth token in isolation — and never seeing that they are one agent.
- Assuming valid means legitimate. Reading a successful auth as benign because the credential was real, when abuse leaves exactly that footprint.
- Stopping at “the key was used.” Confirming a credential was active without asking whose it really is, or whether the agent or a thief was behind it.
- Ignoring what was created. Overlooking new credentials and grants minted during the incident — the persistence the abuse plants.
- Skipping the inventory. Starting analysis before enumerating the agent’s full credential set, and missing abuse of the identities you never listed.
Where Agent Autopsy fits
Agent Autopsy treats identity resolution as a first-class capability: it stitches an agent’s many non-human identities into a single actor, reconstructs what each credential read, called, changed, and decided from the logs you already have, separates the agent’s own use from impersonation, traces abuse to its origin — frequently a prompt injection — and produces a confidence-rated, chain-of-custody-backed account. It is one application of the broader discipline of AI agent forensics. See how it works end to end, how it is validated, or where it fits in the wider AI-agent incident-response process.
Frequently asked questions
What is a non-human identity, and why does it matter in an investigation?
A non-human identity is a credential software authenticates with — an API key, service principal, role, OAuth token, or certificate — rather than a person. It matters because there is no human to pivot on: a single agent acts through many of them, so attributing activity means resolving that sprawl back to one actor before any analysis makes sense.
The token was valid — how do you tell abuse from normal use?
By baseline and context. A valid credential used maliciously produces the same success log as normal use, so the signal is in the deviation: unfamiliar resources, scope beyond the agent’s usual reach, anomalous timing, source, or volume, set against what that identity normally does.
How do you investigate an agent with dozens of credentials across clouds and SaaS?
You enumerate every identity first, then stitch them into one actor so activity across providers reads as a single story. Fused onto a common timeline, the agent’s behavior becomes coherent and the abuse becomes visible — where individual logs each looked unremarkable.
Was it the agent misusing its own access, or someone using stolen credentials?
That distinction is a core output of the investigation. Stolen-credential use tends to carry anomalies the agent’s own activity would not — an unexpected source, client, or geography — while self-misuse usually traces to a hijack or excessive agency. The two demand different responses, so the account has to establish which it was.