Limitations

This page is the list of things NHI Security does not do, stated plainly so you can plan around them rather than discover them. Everything here is true of the product as shipped; nothing here is a promise about what comes next.

​

Discovery

No connector discovers AI agents. The model has a first-class AI agent type, twelve policies about agents, and a runtime gate that authorizes an agent’s actions — and nothing in the AWS, GitHub, Kubernetes, Vault or MCP connectors ever reports one. An agent exists in your organization only because you put it there, through a connector you build against the discovery contract or through demonstration seeding. No API creates an agent by hand, deliberately: inventory has exactly one entrance. This is the single most important sentence on this page. NHI Security can authorize an AI agent’s action. It cannot find one for you. Only some identity types are produced. Of the eighteen types in the model, the shipped connectors produce seven. There is no connector for Azure, Google Cloud, GitLab, Jenkins, Okta, Microsoft Entra ID, Google Workspace, cloud secret managers or SaaS applications. Only AWS produces credentials, all of them access keys. The credential model covers API keys, tokens, certificates, SSH keys and federated trust; nothing collects them. Only GitHub and MCP produce resources. A policy that needs a resource’s classification has nothing to classify on an estate connected to anything else. Activity and credential exposure are not collected at all. Five activity policies and credential_exposed depend on them and report as unavailable until you send the data through the ingestion endpoints yourself. See Findings and risk. Agent lineage is never available. No adapter produces the “created by” edge agent_lineage_unknown needs, so that policy is unavailable on every estate. shadow_agent_unprofiled cannot raise a finding at all — its only outcomes are pass and not assessable.

​

Acting on what you find

Nothing NHI Security records changes anything at a provider by itself. Quarantining an identity is a state in NHI Security; the identity keeps working at AWS. Marking a discovered credential revoked records that it should not be trusted; it does not revoke it. The only thing quarantine enforces is the runtime gate, which denies every action a quarantined identity asks about. Remediation execution is gated twice. Even an approved action only runs if the deployment has execution enabled and there is an executor for that provider. The remediation summary reports whether execution is enabled at all — check it before planning a workflow around it. An approved policy exception does not suppress its finding. The exception is recorded, approved and visible on the exceptions pages, and the finding it exempts still appears in the queue, still counts as open, and still contributes its full points to the identity’s risk score. Treat an exception as a governance record today, not as a filter.

​

Scheduling and background work

There is no evaluation scheduler. Evaluation runs when a person asks for it, or straight after a synchronization that collected something. It is synchronous — the request returns when the run finishes — so a large estate can exhaust an HTTP timeout. Scheduled discovery is off unless the deployment enables it, and when enabled it runs in one process on one node. Nothing expires anything in the background. Access grants, policy exceptions, authority delegations and certification campaigns all stop being in force on their end date, evaluated whenever they are read, so enforcement is correct. But their stored state stays as it was, and the expired audit record is never written. Expired access grants can be closed by calling the expirations route; the others have no route at all.

​

Authentication and integration

NHI Security has no API keys. Every console and API request is authenticated by your TRUSTIVAN session; the only other credential is the runtime bearer token, which reaches the mediation endpoints and nothing else. A pipeline that ingests activity or exposures has to carry a session, which makes it an integration to design rather than a header to set. Runtime credentials cannot be rotated. There is no rotate route and no rotation state. Issue the replacement, move the runtime onto it, revoke the old one. The token is shown once and cannot be read back. Runtime credentials are API-only. There is no console screen for issuing or revoking one. lastUsedAt on a runtime credential is always empty. Nothing records a credential’s use. Several fields recorded on a gate decision are not readable. The source address, the request id, the agent session and the customer credential named in the request are stored or discarded rather than returned by any read route, and the decision log’s agent-session filter can never match anything. The evidence for a decision is returned without its raw payload.

​

People, roles and offboarding

Inside TRUSTIVAN, NHI Security manages nobody. Its own sign-in, invitation, profile-edit and role-edit endpoints answer 404. People, roles, MFA and SSO all belong to AppSec’s Members settings. Removing someone there is what removes their access here: NHI Security re-reads TRUSTIVAN’s answer on every request, caching a success for at most 30 seconds and never caching a refusal, so a removal takes effect within that window. Three of the six NHI Security roles are unreachable. TRUSTIVAN’s Owner and Admin map to Organization Admin, Member to Security Analyst, and Viewer to Viewer. Nobody holds Security Admin, Developer or Auditor. Approving anything needs two Owners or Admins. Every approval refuses the person who requested it, and every approving permission belongs to Organization Admin. A one-person organization can request and can never approve. Requesting a runtime access grant is itself an Organization Admin permission, so that flow needs two of them. Only an Organization Admin can read the audit trail. audit:read is not part of the read-only set, so a Security Analyst and a Viewer cannot see it. In standalone NHI Security this is what the Auditor role is for; inside TRUSTIVAN nobody maps to it.

​

Audit and evidence

The hash chain is not a signature. It is an unkeyed SHA-256, and it makes alteration detectable — not impossible. It does not prove who wrote a record, and it would not defeat someone with database write access who rewrote every following digest. There is no retention policy and no retention job. Audit records accumulate. Deletion is refused by the database unless a transaction opts into a retention operation, and nothing in the product does. Gate decisions are not in the audit trail. They live in the runtime decision log, which is equally append-only and immutable, and which every role can read. Evidence export is capped at 5,000 records per request, and reports truncation with a resume point rather than trimming quietly.

​

Smaller things

• exposureId, resourceId and subjectKind are accepted by the findings list endpoint and have no effect on the results.
• A risk score is clamped at 100, so two critical findings and ten are the same number. The severity, the finding count and the contributing findings are all shown beside it for that reason.
• Every graph edge comes from a connector. Nothing in the console lets a person draw one.
• The credential standing thresholds — 90 days for rotation, 14 days before expiry — apply to the whole deployment. Only the matching policies’ thresholds are tunable per organization.
• One approval is enough for a grant or an exception, and the threshold is set for the deployment, not per organization or per risk level.
• An access grant matches on its target, not on the operation: a grant on a tool covers any operation against that tool for the length of the window.
• stale and orphaned are lifecycle states nothing sets; an unused identity is reported as a stale_identity finding instead.

​

Where to go next