What Is Non-Human Identity (NHI) Security?

What is a non-human identity?

A non-human identity (NHI) is any credentialed identity that is not a person: a cloud IAM role, a Kubernetes service account, a CI/CD robot, an API key, or an AI agent acting on a system’s behalf. In most estates these outnumber human accounts, often by a wide margin, and a large share of them have no owner anyone could name if asked.

Why does non-human identity need its own security discipline?

Because the access-review habits built for people do not transfer. A person has a manager who can be asked “does this account still need this access,” an onboarding and offboarding process, and a name attached to their actions. A service account created for a one-off migration three years ago has none of that — nobody reviews it, nobody owns it in any enforceable sense, and by the time someone notices it still has standing access to production, the person who created it has often left. NHI security is the practice of inventorying these identities, attributing ownership, mapping what each one can actually reach, and deciding whether a given action should be allowed — rather than assuming a credential that has always been able to do something should keep being able to.

What does TRUSTIVAN NHI Security actually do?

Six stages, each built and tested in the product:

1. Discover. Connectors for AWS, GitHub, Kubernetes and HashiCorp Vault inventory the non-human identities each provider reports — IAM roles and machine users, app installations and bot accounts, Kubernetes service accounts, Vault machine entities — and deliberately leave people’s accounts out. An MCP connector lists the tools a Model Context Protocol server exposes.
2. Attribute and map. Each discovered record becomes one identity with an owner, and a graph links identity to credential to permission to resource, so “what can this service account actually reach, and how” has an answer instead of a guess.
3. Assess. Policies run over that evidence and produce findings and a derived risk score per identity. An exception is scoped, approved and expires — it never silently widens.
4. Authorize at runtime. When an AI agent in the inventory tries to act, a runtime gate decides allow, challenge or deny against declared tool entitlements and runtime rules, and records the decision immutably.
5. Control. Just-in-time access grants bounded at seven days, with no self-approval; agent runtime credentials shown once and stored only as a digest; reversible quarantine of an identity.
6. Audit. An append-only, hash-chained trail per tenant, with tenant isolation enforced by row-level security in the database rather than by application code alone.

Authorizing an AI agent’s action vs. discovering one

This is the question most often asked wrong, so it is worth being precise: NHI security does not discover AI agents. No connector reports one and no screen creates one. What it does is authorize an already-inventoried agent’s action — when an AI agent already in the inventory tries to act, a runtime gate decides allow, challenge or deny. It cannot find agents nobody has recorded; if your environment runs agents that were never registered anywhere a connector can see, they are not in scope yet.

What are the connectors, and what do they read?

Connector	What it inventories
AWS	IAM roles and IAM users that are evidently machine identities, the relationships between them, and (alone among the connectors) access-key metadata and inline-policy permissions
GitHub	App installations and the accounts GitHub itself marks as bots, read with two read-only permissions
Kubernetes	ServiceAccounts (non-human by construction), their role bindings, and the workloads that run as them — secrets are never read
HashiCorp Vault	Entities that arrive through machine auth methods; human-capable ones are excluded
MCP tool servers	The tools a server publishes; tested against a deterministic fake server, not yet run against a live one

A connector stores a reference to its credentials, never the credentials themselves, and classifies an identity from what the provider reports about it — never from its name — reporting an unrecognised kind as unknown rather than guessing.

What does NHI security not do yet?

Stated plainly, because an evaluation that discovers these later has wasted time: it has not been deployed to production (it is built, tested, and runs locally and in containers); it changes nothing in a connected cloud account by default (remediation is proposed and dry-run inside the product, and executing it against a provider requires an operator to opt in); there is no behavioural analytics beyond two narrow runtime rules, no agent-to-agent lineage, and no endpoint telemetry; and certification, delegation, drift and compliance exist as API surfaces without console screens yet.

How does NHI security relate to TRUSTIVAN AppSec?

They are the two halves of one product, sharing one sign-in, one organization model and one address, each with its own backend and database. AppSec governs what your software contains — container images, repositories, SBOMs. NHI Security governs the identities your software runs as. See NHI Security for the full page, or the glossary for short definitions of the terms above.