Non-Human Identities

NHI types

One inventory model. One authorization check. Different paths to how the identity acts.

• AI Agents

  Identities that call tools, APIs, and MCP servers without a human login session. Newest NHI class — not the whole class.

  Open AI Agent Security

• Service Accounts

  Standing credentials used by applications. They need an owner, a review cycle, and an expiry — or they become permanent access.

• Service Principals

  Cloud identities for apps and workloads. Same inventory and authorization model as other NHI, not a separate spreadsheet.

• Workload Identities

  Roles assumed at runtime. Authorize the action the workload takes, not only the cluster or cloud login that minted the identity.

• Machine Identities

  Hosts and devices that present an identity to APIs and infrastructure. They belong in the same inventory as agents, with an owner.

• Application Identities

  The application as an actor — not the human who deployed it. Map it to owners, tools, and resources.

• Bots

  Chat, ops, and workflow bots that change tickets, files, or production systems. Treat the bot as the subject of the check.

• Automation Identities

  CI/CD jobs, schedulers, and scripts. Short-lived or standing, they still need identity, policy, and a trail.

• API / Service Identities

  Callers that authenticate with keys or tokens. Govern the identity behind the credential, not only the secret string.

Machine identity

Machines and devices that present an identity to APIs and infrastructure belong in the same inventory as agents. A host certificate or device credential is still an identity: it needs an owner, a lifecycle, and a decision when it calls something that matters.

This page does not claim a separate machine-identity product, a SPIFFE mesh, or automatic discovery of every device. Those are playbooks. The identity still has to be findable here.

Workload identity

Workloads that assume roles at runtime are NHI. Cloud role assumption answers “who minted this session?”. Authorization still has to answer “may this subject perform this action on this resource, in this context?”

Least privilege at cluster login is not least privilege for the payment call, the file write, or the MCP tool behind that workload.

Service identity

Service accounts, service principals, and API identities are standing access unless you govern them. A key in a vault without an owner on the identity is still an orphan with a nicer UI.

Credential governance in this product is part of identity — rotate and revoke as lifecycle, not as a disconnected secrets screen. It is not a replacement for a secrets manager you already run.

Inventory and orphan owners

If it can act, it must be findable. Identities without an owner are a governance defect, not a footnote. Register what you know. Discover more when a connector exists. Without a connector, inventory is manual registration and SDK reporting — not a promise that every cloud account appears on its own.

Governance, not a sidecar spreadsheet

Create, review, expire, revoke. Least privilege is a baseline you attach to the identity, then a decision at the time of the action. Organization owns users. Tenant owns agents, NHI, policies, and resources — so a software house can keep customer environments apart. Tenancy detail is on the product page.

Why this page is not “NHI Security”

NHI is a category of identities. The product is QData Identity Security: broader than inventory, and not a synonym for AI Agent Security. Using “NHI Security” as the name of the whole offer would collapse agents, authorization, and enforcement into a single adjective.

Related pages

• AI Agent Security

  The newest NHI class: tools, MCP, no human session.

  Open AI Agent Security

• Authorization

  The check that applies to every type on this page.

  Open authorization

• QData Identity Security

  Inventory through audit — the product, not this category page.

  Explore the platform

• Security model

  Inventory without a PEP is still observe.

  See security

Questions