Non-human identity (NHI) for AI agents is the work of giving each agent an identity, an owner and a lifecycle. Identity and access management (IAM) answers who the agent is. It does not decide what each individual call to a third-party API may do or return. Per-call enforcement completes the NHI programme.
That is a complementary claim. The identity platform stays. The missing decision is on the outbound hop.
The agent that inherited the batch account
An IAM lead at a superannuation trustee had just closed a service-account clean-up. Every leftover key had an owner in the CMDB. The following Monday a proof-of-concept assistant started reading member records through the same overnight batch account the clean-up had just tagged as “finance-recon”. The identity of the batch job was in good order. The assistant had no identity of its own. The trustee could answer who the account was. It could not answer which caller used it at 14:12, or whether that caller was allowed to request a full member object.
Cloud Security Alliance’s Non-Human Identity Governance Vacuum states the scale first: NHIs “now outnumber human users by an average of 45 to 1.” In cloud-native estates the same paper puts the ratio at 144 to 1. A 2026 CSA analysis of token sprawl found that more than 16% of organisations do not track the creation of AI-related identities at all. Only 15% of organisations in a 2024 CSA survey felt highly confident they could prevent NHI-based attacks.
KuppingerCole, writing in 2026, puts machine identities at more than 50 per human and cites Palo Alto Networks’ 2026 Identity Security Landscape: 109 machine identities per human, up from 82, with 79 of those 109 described as AI agents. Treat the 79 figure with care – a census of everything marketed as an agent will over-count autonomy – but the direction is not in dispute. The population IAM was asked to enrol is no longer mostly batch jobs.
What does IAM cover for agents?
It covers enrolment, authentication, grouping, and often a coarse entitlement: this agent may use this application or this OAuth client.
CSA’s Defining Non-Human Identity distinguishes agent identities as autonomous actors with delegated authority, whose governance problems are impersonation, excessive action authority and incomplete audit across delegator, agent, intent and action. KuppingerCole’s From Identity to Access makes the same cut: dependent identities (workloads) fail through scale; autonomous identities fail through missing accountability and unbounded blast radius. Identity is necessary. Access, enforced at the resource, is where governance is decided.
A good NHI programme will:
- give the agent an identity that is not a copied human
- assign an owner and a review date
- prefer short-lived credentials
- record join-move-leave
Those steps answer “who”. They do not evaluate GET /members/123?expand=all against a purpose.
What gap does IAM leave at the API call?
The gap is the request to an API the organisation does not host: method, path, request shape, and the fields that return.
The identity token is valid. The vendor key, often still a shared one, is valid. The call is still wrong for this assistant. No IdP sits in that HTTPS exchange. Outbound API governance is the name for the layer that does. A credential-less agent is how the vendor key stays off the principal. The layer map shows why buying a stronger IdP does not close the hop.
APRA’s April 2026 AI letter made the same observation for regulated entities: IAM has not adjusted to non-human actors, and staff AI use often lacks preventative technical controls.
How per-call enforcement completes the programme
It attaches a grant to the identity you just created.
| NHI question | IAM answer | Per-call completion |
|---|---|---|
| Who is this? | Agent identity, not a shared human | Same identity presented as the proxy caller |
| Who owns it? | Owner in the identity source | Owner also owns the proxy and its rules |
| What may it use? | App or OAuth client | Named methods and paths on the third-party API |
| What may it see? | Rarely specified | Field- and row-level filters on the response |
| What did it do? | Sign-in and sometimes token events | Allow and deny on each outbound call |
Without the right-hand column, NHI is an accurate census of keys. With it, the census has a runtime.
A practical sequence for an IAM team that already has an NHI workstream:
- Enrol the agent in the identity source with an owner, an expiry and a purpose string a human can read.
- Stop sharing human and batch credentials. The overnight recon account is not an assistant identity even if the CMDB owner field is filled in.
- Issue a caller secret that is useless at the vendor. The IdP token or proxy credential proves who. It must not be the Salesforce refresh token.
- Attach the grant on the outbound hop. Methods, paths and response fields are the job description CSA said agents lack.
- Review the audit in the same cycle as the identity recertification. An identity that is still “in date” but now writes to payroll has already left the programme.
That sequence is what “completes the NHI programme” means in operations, not in a slide. It also matches APRA’s observation that preventative technical controls, not only policy, are what staff and agent use still lack.
Desktop MCP clients deserve a line of their own. They often inherit the signed-in user’s Graph or CRM session. Enrolment in the IdP then looks complete – the human authenticated – while the process on the laptop is a second principal with no grant of its own. Treat the desktop client as an NHI. Put the vendor API behind a caller the laptop config does not own.
CSA’s agent-identity language is useful here because it names four audit fields: delegator, agent, intent and action. IAM usually records the first two. The outbound hop records the last two, if you log the grant decision with the request. A recertification that only asks “does this service principal still have an owner?” will keep a healthy identity attached to an unhealthy grant. Recertify the grant in the same cycle.
That is also why a copied human identity is worse than a missing one. The batch account in the opening scenario had an owner. The assistant inherited the owner’s implied purpose. The log said finance-recon. The work was a chat session. Identity without a per-call grant will keep producing that mismatch as agents multiply.
Where RequestRocket fits
RequestRocket does not replace the identity provider. It uses the caller you already enrolled – or a proxy credential you issue for that agent – and enforces what each outbound call may do. It holds the vendor secret, applies rules and filters, and records the trail. It provides no models. It is the access decision KuppingerCole locates at the resource, for APIs you do not host.
FAQ
Are AI agents just another NHI?
They are NHIs, but they are not just another service account. CSA and KuppingerCole both treat agents as autonomous actors. Their failure mode is an unbounded sequence of valid calls, not only a leaked static key.
What NHI-to-human ratio should we plan for?
Published ranges run from tens-to-one to over a hundred-to-one depending on scope. CSA cites 45:1 on average and 144:1 in cloud-native estates. KuppingerCole cites more than 50:1 and Palo Alto’s 109:1. Use your own inventory. Do not wait for a single industry number.
Does SPIFFE or workload identity close the gap?
Workload identity proves the process. It does not evaluate the Salesforce path the process is about to call. Keep SPIFFE. Add the call decision.
Should every agent have its own vendor OAuth app?
That is ideal at the vendor and often impossible. A proxy lets many agent identities share one stored vendor grant without sharing blast radius.
Is this the same as privileged access management?
PAM governs how humans and some workloads check out powerful credentials. Per-call outbound rules govern what happens after a credential is in use against a third-party API.
Where do desktop MCP agents fit?
They are NHIs that often inherit the human’s session. Enrol them, then put the vendor API behind a grant the desktop process does not own.
Book a walkthrough of RequestRocket
Sources
- CSA, The Non-Human Identity Governance Vacuum
- CSA, Defining Non-Human Identity
- KuppingerCole, Your Identity Fabric Wasn’t Built for AI Agents
- KuppingerCole, When AI Agents Break the Security Model
- KuppingerCole, From Identity to Access: Locating the Control Point
- APRA, Letter to Industry on Artificial Intelligence (30 April 2026)