A non-human consumer is any service, bot, workload, or AI agent that calls an API on behalf of a process rather than a person. These actors create identity and authorisation challenges because they can be authenticated, widely distributed, and difficult to govern with human-centric controls.
Expanded Definition
In identity security, a non-human consumer is the calling side of machine-to-machine access: a workload, service, bot, or agent that requests data or actions through an API without a person directly operating each request. The term is narrower than “non-human identity” because it describes a usage pattern, not the full identity lifecycle or governance model behind it.
That distinction matters. A non-human consumer may authenticate with a client secret, token, certificate, or delegated credential, but the security question is usually how that caller is identified, authorised, scoped, and monitored. It is not the same as a user account that happens to be automated, and it is not simply “an API client” in the abstract. The most common boundary mistake is to treat every machine caller as interchangeable, when different callers have very different trust, rotation, and ownership requirements.
For a structured view of machine identity risk, the OWASP Non-Human Identity Top 10 is a useful companion reference because it frames the governance issues that arise when machines become persistent consumers of protected services.
Examples and Use Cases
Non-human consumers appear anywhere software must call software at scale. The same pattern can be low-risk in one system and highly sensitive in another, depending on what the consumer can reach and how long its access persists.
- A payment reconciliation service pulls transaction records from an internal API on a fixed schedule, using a machine credential rather than a human session.
- A CI/CD pipeline calls deployment and secrets-management APIs to promote builds, create resources, or roll back releases.
- An alerting bot queries an observability platform and opens tickets based on threshold logic.
- An AI agent invokes tools or APIs to retrieve context, write records, or trigger workflow steps on behalf of an operator or another system.
The implementation tradeoff is straightforward: the more autonomous and distributed the consumer, the harder it becomes to rely on human approval, manual review, or interactive sign-in. That is why ownership, scope, and revocation need to be defined at the machine level, not inferred from the application team alone.
Security Implications
When a non-human consumer is poorly governed, the failure is usually not “login abuse” in the human sense. The more common problem is durable, over-scoped, or invisible access that keeps working long after the original need has changed. That can expose APIs, internal datasets, administrative functions, or workflow actions to unintended systems.
Because these consumers can be distributed across pipelines, containers, devices, and autonomous tools, the blast radius can be wide. A single leaked token, stale certificate, or mis-scoped service credential may allow repeatable access without triggering the kinds of behavioural signals defenders expect from human users. Operational symptoms often include hard-to-attribute API traffic, unowned credentials, or service accounts that outlive the workload they were created for.
The practical consequence is governance drift: authorisation becomes harder to explain, audit, and remove. In machine-to-machine environments, the most dangerous issue is often not a dramatic compromise but a quiet accumulation of access that no one can confidently justify.
Domain and Governance Relevance
For NHI governance, the term is important because it highlights the consumer side of machine access, not just the identity that issues the call. A non-human consumer can be a legitimate workload, but it still needs explicit ownership, purpose, scope, and lifecycle control if the environment is to remain auditable.
This is especially relevant when autonomous agents are involved. Once an AI agent can invoke tools or APIs, the consumer is no longer just a backend integration. It becomes an execution actor whose privileges, request paths, and operational boundaries can change the trust model of the entire workflow.
That shift affects how organisations think about machine identity inventory, delegated authority, and offboarding. In practice, the governance question is not whether the consumer is “human or machine,” but whether its access can be explained, bounded, and revoked with the same discipline expected for any high-trust identity.
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, OWASP Non-Human Identity Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Non-human consumers are a core machine-identity inventory and ownership problem. |
| Recommendation: Track each machine consumer to a named owner, purpose, and lifecycle state. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 | These consumers typically authenticate with tokens, secrets, or certificates. |
| Recommendation: Machine callers need credential handling that is distinct from human authentication flows. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 | Their primary risk is over-scoped API access and durable machine authorization. |
| Recommendation: Scope each consumer to the minimum actions and resources its workflow requires. | ||
| NIST CSF 2.0 | PR.AA | Machine consumers need controlled identity, authentication, and access decisions. |
| Recommendation: Apply identity and access governance to non-human access paths, not only users. | ||
| CIS Controls v8 | 6.3 | Non-human consumers depend on disciplined provisioning and removal of machine access. |
| Recommendation: Provision and revoke machine access through a controlled, auditable process. | ||
