NHI Security Overview

NHI Security is the part of TRUSTIVAN that inventories and assesses non-human identities: IAM roles, machine IAM users, GitHub App installations and bot accounts, Kubernetes ServiceAccounts, Vault AppRoles and similar identities that software uses to authenticate. People sign in; non-human identities are issued credentials and act continuously, usually with nobody watching. NHI Security connects to the environments where those identities live, reads what exists, and helps you answer:

• What non-human identities exist? Each one is recorded with its type, provider, lifecycle state and the evidence that observed it.
• Who is accountable for each one? Ownership comes from provider tags and annotations where they exist, or from an owner you assign.
• What can it reach? Trust, group membership and permission attachments are drawn as a graph you can follow.
• What is wrong with it? A catalogue of policies turns the evidence into findings, and risk per identity is derived from those findings.
• Who changed what? Security-relevant actions are written to a hash-chained audit trail.

It also contains a runtime gate that answers allow, challenge or deny when an AI agent runtime asks whether it may take an action. Read that page before planning around it: no connector reports an AI agent today, so in an organization filled only by connectors the gate has no agent to act for.

​

How it relates to TRUSTIVAN AppSec

TRUSTIVAN has two parts that share one sign-in, one organization and one address: Both consoles show the same product switcher, AppSec | NHI Security, so you move between them without signing in again. The two parts keep separate backends and separate databases. NHI Security never verifies your TRUSTIVAN session itself. It forwards your session cookie to TRUSTIVAN (GET /api/v1/me/context) and acts on the answer:

• Your TRUSTIVAN organization maps to exactly one NHI Security organization. It is created the first time anyone from your organization opens NHI Security, and your own NHI Security account is created the first time you do.
• Your TRUSTIVAN role decides your NHI Security role. The mapping is applied again every time TRUSTIVAN’s answer is fetched, so a role change in TRUSTIVAN reaches NHI Security within the cache window below.
• A successful answer is reused for at most 30 seconds by default, and never more than 60. A refusal is never reused.
• If TRUSTIVAN cannot be reached, answers with an error, or times out, NHI Security refuses the request as unauthenticated. It never falls back to an earlier answer.
• If your organization does not have the NHI Security feature (nhi_security), you are signed in but NHI Security answers that the product is not enabled for your organization, and creates nothing for you. The feature is currently enabled on every plan.

NHI Security defines three further roles (Security Admin, Developer and Auditor). No TRUSTIVAN role maps to them, so nobody holds them when NHI Security runs inside TRUSTIVAN. Several NHI Security approvals refuse the person who made the request, whatever their role. Because only TRUSTIVAN Owners and Admins become Organization Admins, approving a remediation, a policy exception or a runtime access grant needs a second Owner or Admin in your organization.

​

What NHI Security will not show you

NHI Security only states what a connector has observed. On an organization that has connected nothing, the overview says No environment is connected rather than showing zeros. A policy whose required facts no connected environment supplies is reported as unavailable, with the missing fact named, rather than as a clean result. Expect to see both while your first connectors are being set up.

​

Where to go next

For how AppSec separates organizations, see Tenancy and the security model.