Connectors

NHI Security ships five connectors. Each one only reads from your provider, and asks for the smallest set of permissions it needs.

Connector	Collects	Capabilities	Create from the console
AWS	IAM roles, machine IAM users, access keys, inline policy statements, trust and group relationships	Identities, Relationships, Credential metadata, Permissions	Yes
GitHub	GitHub App installations, bot accounts, repositories	Identities, Relationships, Resources	Yes
Kubernetes	ServiceAccounts, RBAC bindings, the workloads that run as each account	Identities, Relationships	Yes
HashiCorp Vault	AppRoles, machine identity entities, their policies and auth mounts	Identities, Relationships	Yes
MCP	The tools an MCP server publishes	Tools, Resources, Relationships	No, API only

The console’s connector form lists every capability for every provider. A connector that asks for a capability its provider does not support is refused, so select only the ones in the table.

Rules that apply to every connector

Credentials references

Connector credentials are never typed into the console. The connector form asks for a credentials reference, which is a name, and NHI Security refuses a reference that looks like a secret. The name must resolve to an entry your deployment holds, or the synchronization fails with a configuration_error before any provider call. There are two ways an entry comes to exist:

In your deployment’s configuration, registered by whoever operates your TRUSTIVAN deployment. This is the route for a first connector, and the only route for the AWS mode that uses the deployment’s own identity.
Through the API, by an Organization Admin: POST /nhi/api/v1/credentials/material stores the values encrypted at rest. The console has no screen for it, and it attaches the material to an identity that is already in your inventory, so it cannot be used before a first connector has synchronized.

Which of the two your deployment reads is a deployment setting. The field names each connector expects are listed below so you can tell your operator exactly what to register.

Endpoints

Public HTTPS only, on port 443, 6443 or 8443. Private, loopback, link-local, carrier-grade NAT and cloud metadata addresses are refused, as are localhost and names ending in .internal, .local or .localdomain. A provider reachable only inside your network, such as a private Kubernetes API server or an internal Vault, cannot be connected today.
Permitted hosts only. AWS and GitHub have built-in permitted hosts. Kubernetes and Vault have built-in hosts for managed offerings, and any other host must be allowed by your deployment operator. MCP has no built-in hosts at all.
For GitHub, Kubernetes, Vault and MCP, the hostname is resolved and every resolved address is checked, redirects are refused, and responses are size-limited.

People are left out

A human’s account never enters the inventory or the graph. Where a provider cannot tell a machine from a person, the account is either excluded or recorded as unknown, never guessed from its name.

Last use is shown only where the provider reports it

Of the five, only AWS reports last use, and only for roles and access keys. Everywhere else NHI Security shows that last use is not reported, rather than implying the identity was never used. This is why the stale_identity policy reports identities from other providers as not assessable rather than as unused.

Requests are paced and retried

Each connector makes at most 10 requests per second. Throttling, timeouts and provider outages are retried with growing delays, up to three attempts in total, and a provider’s Retry-After is obeyed. Authentication and authorization failures are never retried.

AWS

Discovers the non-human identity surface of one AWS account per connector.

What it collects

AWS object	Recorded as
IAM role	Identity, type `iam_role`, with last use where AWS reports it
IAM user with no console sign-in profile and at least one access key	Identity, type `service_account`
IAM user with no console profile and no keys	Identity, type `unknown`
IAM user with a console sign-in profile	Not collected. It is a person’s account, and its keys are not listed
Access key on a machine user	Credential, type `access_key`, with key ID, status, creation time and last use
`Allow` statement in an inline policy on a role, machine user or group	Permission, one per statement

Relationships: ASSUMES (from each role’s trust policy), HAS_PERMISSION (attached managed and inline policies), BELONGS_TO (group membership), and ACCESSES to each specific ARN an inline Allow statement names.Ownership comes from tags, matched without regard to case. Owner, OwnerEmail, Owner_Email, Contact and ContactEmail are declared. Team, ManagedBy (and Managed-By, Managed_By), CreatedBy (and Created-By), BusinessUnit and aws:cloudformation:stack-name are inferred.

Permissions it needs

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NhiDiscovery",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountAuthorizationDetails",
        "iam:GetLoginProfile",
        "iam:ListAccessKeys",
        "iam:GetAccessKeyLastUsed"
      ],
      "Resource": "*"
    },
    {
      "Sid": "NhiIdentityCheck",
      "Effect": "Allow",
      "Action": "sts:GetCallerIdentity",
      "Resource": "*"
    }
  ]
}

You can drop iam:GetLoginProfile, iam:ListAccessKeys and iam:GetAccessKeyLastUsed if you set includeUsers to false, and drop iam:GetAccessKeyLastUsed alone if you set includeKeyLastUsed to false. Removing them without changing the setting records the affected users as unknown and marks the run partially_failed.

Authentication

Mode	Console label	What your operator registers
`assume_role` (default)	Assume a role in the target account (recommended)	An entry with no values. No long-lived key is stored
`access_key`	A stored access key	`accessKeyId`, `secretAccessKey`, optionally `sessionToken`
`ambient`	This deployment’s own identity	An entry in the deployment’s configuration. An entry stored through the API is refused for this mode

In assume_role mode the role’s trust policy must trust your deployment’s AWS principal and require the connector’s External ID, which is connector-<connector id> and is shown on the connector page. NHI Security generates it and always sends it; an external ID supplied in settings or credentials is refused.Before reading anything, on every health check and every synchronization, the connector calls sts:GetCallerIdentity and refuses to collect if the credentials belong to a different account from the one on the connector.

Settings

Setting	Default	Notes
`authMode`	`assume_role`	See above
`roleArn`	none	Required for `assume_role`
`region`	`us-east-1`	IAM is global; this selects the partition’s endpoint. API only
`includeUsers`	`true`	Two extra API calls per IAM user
`includeKeyLastUsed`	`true`	One extra API call per access key. API only
`pathPrefix`	none	Only record IAM objects under this path. Applied by the connector after reading, not by AWS. API only
`pageSize`	`100`	1 to 1000. API only

Settings marked API only are not on the console form; set them with PATCH /nhi/api/v1/connectors/{connectorId}. The account ID always comes from the connector’s scope, never from settings.

What it does not do

Managed policy documents are not read. The HAS_PERMISSION edge to a managed policy is drawn, but its statements are not collected.
Deny statements are not recorded, and conditions are not evaluated. A conditional Allow is recorded and flagged as conditional. NotAction and NotResource statements are recorded as wildcard grants. Access computed from AWS data is therefore an upper bound.
Account principals in trust policies are not expanded. A role that trusts arn:aws:iam::123456789012:root does not produce an edge from every principal in that account.
Resources are not discovered. Buckets, databases and other AWS resources are not collected.
One account per connector. There is no AWS Organizations-wide discovery.

GitHub

Discovers the machine identities of one GitHub organization on github.com. GitHub Enterprise Server is not supported.

What it collects

GitHub object	Recorded as
GitHub App installation in the organization	Identity, type `service_principal`
Organization member GitHub reports as `Bot`	Identity, type `bot`
Organization member of type `User`	Not collected, even if it is used for automation
Repository	Resource, with its visibility and whether it is archived

Relationships: installations and bots BELONGS_TO the organization; each installation HAS_PERMISSION for each App permission (for example contents:write); a bot HAS_PERMISSION for the organization admin role where it holds it.GitHub states no owner and no last use for installations or bots, so none is recorded.

Permissions it needs

A fine-grained personal access token for the organization, with read access to the organization permissions that cover these calls:

Call	Used for
`GET /orgs/{org}`	Confirming the organization on the connector
`GET /orgs/{org}/installations`	GitHub App installations (Administration, read)
`GET /orgs/{org}/members`	Bot members (Members, read)
`GET /orgs/{org}/repos?type=all`	Repositories the token can see

To include private and internal repositories, give the token access to them.

Authentication and settings

One mode, token. Your operator registers the token under the field name token. GitHub App authentication is not implemented.

Setting	Default	Notes
`includeApps`	`true`	Enumerate installed GitHub Apps
`includeBots`	`true`	Enumerate bot members
`pageSize`	`50`	1 to 100. API only

Turning off both includeApps and includeBots is refused.

What it does not do

It does not discover Actions workflow identities, secrets, deploy keys or runners.
It does not read the audit log or secret-scanning alerts.
It does not know which repositories an installation can reach, so it draws no installation-to-repository edge.
Its organization check is weak: any token can read a public organization, so a healthy result mainly proves that the next call, listing installations or members, was permitted.

Kubernetes

Discovers the ServiceAccounts of one cluster and what they are bound to.

What it collects

Kubernetes object	Recorded as
ServiceAccount	Identity, type `kubernetes_service_account`, identified by `namespace/name`, with a `BELONGS_TO` edge to its namespace
RoleBinding, ClusterRoleBinding	`HAS_PERMISSION` edges from the ServiceAccount to the bound Role or ClusterRole
Deployment, StatefulSet, DaemonSet, CronJob	`USES` edges from the workload to the ServiceAccount it runs as
`eks.amazonaws.com/role-arn` annotation	An inferred `ASSUMES` edge to that AWS IAM role

Pods and Secrets are never read.Ownership comes from annotations and labels. owner, owners, owner-email, contact and contact-email are declared; team, managed-by, part-of, created-by, release-name and instance are inferred. A prefix such as example.com/owner is accepted.

Permissions it needs

list only. For a cluster-wide connector:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nhi-security-inventory
rules:
  - apiGroups: ['']
    resources: ['serviceaccounts']
    verbs: ['list']
  - apiGroups: ['rbac.authorization.k8s.io']
    resources: ['rolebindings', 'clusterrolebindings']
    verbs: ['list']
  - apiGroups: ['apps']
    resources: ['deployments', 'statefulsets', 'daemonsets']
    verbs: ['list']
  - apiGroups: ['batch']
    resources: ['cronjobs']
    verbs: ['list']

The apps and batch rules are needed only while includeWorkloads is on. The health check also reads the API server’s /version, which Kubernetes normally allows to any authenticated caller.For a connector restricted to some namespaces, bind a Role with the namespaced rules in each of those namespaces, plus a ClusterRole with clusterrolebindings only. ClusterRoleBindings are always read, because they are how an account in one namespace gains permission everywhere.

Authentication and settings

One mode, token: a bearer token your operator registers under the field name token. A short-lived ServiceAccount token that you rotate is the best choice. Client certificates are not supported.The Endpoint is required: the cluster’s API server URL. Built-in permitted hosts are eks.amazonaws.com and azmk8s.io; other hosts must be allowed by your deployment operator. The API server’s certificate must be trusted by the deployment; there is no option to skip TLS verification.

Setting	Default	Notes
`namespaces`	whole cluster	Up to 100 namespaces, each read separately
`includeWorkloads`	`true`	Read workloads to learn which account each runs as
`pageSize`	`100`	1 to 500. API only

What it does not do

It cannot detect a connector pointed at the wrong cluster, because Kubernetes has no cluster identity endpoint.
Role and ClusterRole rules are not read, so the graph shows that an account is bound to cluster-admin but not what cluster-admin contains.
A binding to the group system:serviceaccounts:<namespace> is not represented.
Workload identity federation into Google Cloud or Azure produces no edge. It is mentioned only in the ServiceAccount’s evidence.
Last use is not reported.

HashiCorp Vault

Discovers the machine identities of one Vault (HCP Vault, or a self-hosted Vault reachable over public HTTPS).

What it collects

Vault object	Recorded as
AppRole	Identity, type `service_account`, identified by mount and name
Identity entity whose aliases all use machine auth methods (`approle`, `cert`, `aws`, `azure`, `gcp`, `kubernetes`, `alicloud`, `oci`)	Identity: `workload_identity` if any alias is a cloud or cluster method, otherwise `service_account`
Entity with any `userpass`, `ldap`, `okta`, `github`, `oidc` or `radius` alias	Not collected. It is a person
Entity with `jwt` aliases, other mounts, or no aliases	Identity, type `unknown`

Relationships: an AppRole BELONGS_TO its auth mount; AppRoles and entities HAS_PERMISSION for their policies; entities AUTHENTICATES_WITH each alias’s mount; and, where an AWS auth alias names a full IAM ARN, an inferred ASSUMES edge from that AWS principal to the entity.An AppRole with bind_secret_id: false is called out in its evidence, because its role ID alone is enough to authenticate. Vault records no owner and no last use, so none is shown.

Permissions it needs

path "sys/auth" {
  capabilities = ["read"]
}
path "auth/approle/role" {
  capabilities = ["list"]
}
path "auth/approle/role/*" {
  capabilities = ["read"]
}
path "identity/entity/id" {
  capabilities = ["list"]
}
path "identity/entity/id/*" {
  capabilities = ["read"]
}

Add a list and read pair for each additional AppRole mount you configure. The policy never grants access to role IDs or secret IDs.

Authentication and settings

Mode	Console label	What your operator registers
`approle` (default)	AppRole login (recommended)	`roleId` and `secretId`
`token`	A stored token	`token`, ideally a periodic token

The Endpoint is required. hashicorp.cloud is permitted by default; other hosts must be allowed by your deployment operator.

Setting	Default	Notes
`approleMounts`	`["approle"]`	Up to 20 AppRole mounts to enumerate. The health check reports `misconfigured` if one does not exist
`loginMount`	`approle`	The mount used to log in, in `approle` mode. API only
`namespace`	none	Vault Enterprise namespace
`includeEntities`	`true`	Enumerate identity entities as well as AppRoles
`pageSize`	`25`	1 to 100. API only

What it does not do

It does not read AppRole secret ID accessors, so Vault contributes nothing to the credential inventory.
It does not read the audit device, so last use is not reported.

MCP tool servers

Reads the tools a Model Context Protocol server publishes. It reports no identities: an MCP server answers whoever authenticates and does not know its callers.

The MCP connector has been tested only against a simulated server. It has not been run against a live MCP server. The console’s Connect an environment form does not offer it, so an MCP connector is created through the API (POST /nhi/api/v1/connectors with provider set to mcp). Your deployment operator must also allow the server’s host, because MCP has no built-in permitted hosts.

What it collects

MCP object	Recorded as
Each tool in `tools/list`	A tool, shown under Discover → Agent tools
The server	A resource of kind `mcp_server`
Tool to server	`BELONGS_TO` edge
`annotations.readOnlyHint`	The tool’s effect: `read` when true, `write` when false, recorded as publisher-declared

A tool with no hint, or only destructiveHint, has effect unknown. An Organization Admin can declare any tool’s effect on its page.Capabilities (enabledCapabilities): tool_discovery, resource_discovery, relationship_discovery.

What it needs

Field	Value
`scope`	`{ "kind": "instance", "id": "<your name for the server>" }`
`endpoint`	The server’s full MCP URL. Required
`settings.authMode`	`bearer` (default) or `none`
`settings.protocolVersion`	An MCP revision date. Default `2025-06-18`
`settings.pageSize`	1 to 500. Default `100`

For bearer, your operator registers the token under the field name token. The connector only runs the initialize handshake and calls tools/list, so a token restricted to listing tools is enough.

What it does not do

It never calls a tool, and never reads MCP resources or prompts.
It cannot say which agent uses which tool, or which resource a tool acts on. The protocol carries neither fact.
It never decides what a tool does from its name or description.

Providers that are not supported

Azure, Google Cloud, GitLab, Jenkins, Okta, Microsoft Entra ID, Google Workspace, cloud secret managers and SaaS applications have no connector. A connector for a provider NHI Security has no adapter for cannot be created. No connector collects activity or credential exposures. Policies that need either depend on data sent through the ingestion API; see Findings and risk.

Get started

Inventory

Govern

Reference

Rules that apply to every connector

Credentials references

Endpoints

People are left out

Last use is shown only where the provider reports it

Requests are paced and retried

AWS

GitHub

Kubernetes

HashiCorp Vault

MCP tool servers

Providers that are not supported

​Rules that apply to every connector

​Credentials references

​Endpoints

​People are left out

​Last use is shown only where the provider reports it

​Requests are paced and retried

​AWS

​GitHub

​Kubernetes

​HashiCorp Vault

​MCP tool servers

​Providers that are not supported

Rules that apply to every connector

Credentials references

Endpoints

People are left out

Last use is shown only where the provider reports it

Requests are paced and retried

AWS

GitHub

Kubernetes

HashiCorp Vault

MCP tool servers

Providers that are not supported