Discovery & Inventory

Find every identity.Keep finding them.

Connectors discover IAM roles, machine users, access keys, GitHub App installations, Kubernetes ServiceAccounts, Vault AppRoles and MCP tools — then normalize them into one inventory with the same fields, whatever system minted them. No connector discovers an agent.

AvailableM2 · Identity Governance

Read-only connectors · no agents on hosts · no proxies in the request path

Scope

Every identity type. Every connected environment. Repeatedly.

Discovery is not a one-time scan. It is a sync lifecycle that notices the identity nobody remembers creating — and the credential that was attached to it since the last run.

Identity types

IAM roles, machine users, service accounts, App installations, bots and AppRoles — typed on arrival from the provider’s own object kind

Environments

AWS IAM, Kubernetes, HashiCorp Vault, GitHub, Model Context Protocol — every connector that ships today, each read-only

Continuity

Syncs on demand or on a schedule, with change detection between runs — the scheduler ships switched off, so you choose the interval

How it works

One schema for an AWS role, a Kubernetes service account and a GitHub App

Normalization is what turns a pile of connector exports into a question you can ask across systems.

Normalization

Every connector maps onto the same relationship model

Native objects become identities, credentials and resources in one graph: owner → identity → credential → resource. You stop reconciling spreadsheets and start asking what an identity can reach, whoever minted it.

  • Native identifiers preserved, so every record links back to its source object and snapshot.
  • Credentials are separate objects. Identity ≠ credential: a key attached to two identities is reuse, not a duplicate.
  • MCP servers and their tools enter the same graph as resources; no connector reports an agent.
Explore the identity graph
Coverage

Cloud, clusters, code, vaults and MCP — through connectors, not agents

Read-only connectors enumerate identities from the control plane of each system, where identities are actually defined. Nothing is installed on hosts and nothing sits in the request path.

  • AWS IAM and Kubernetes: roles, machine users, access keys, trust, ServiceAccounts, bindings and the workloads that run as them.
  • GitHub and Vault: App installations, bot accounts, repositories, AppRoles, identity entities and auth mounts.
  • MCP servers: each server and the tools it lists — never a tool call, never an agent.
View all integrations
  • AWS IAMRoles, machine users, access-key metadata, trust, inline policy statementsAvailable
  • GitHubApp installations, bot members, repositories and their visibilityAvailable
  • HashiCorp VaultAppRoles, machine identity entities, auth mounts, policy namesAvailable
  • KubernetesService accounts, role bindings, workloads that run as themAvailable
  • Model Context ProtocolMCP servers and their tools, with publisher-declared effectAvailable
Change detection

Discovery as a stream of events, not a quarterly report

Each sync diff becomes an event: identity created, credential attached, grant changed, owner resolved, identity absent. Events carry their connector evidence, so the inventory explains itself — and so the next capability can react to it.

  • On demand or on a schedule, with the scheduler switched off until you turn it on.
  • Deletions are events too: an identity that disappears keeps its history for audits and investigations.
  • Every change lands in the audit trail, hash-chained and exportable as evidence — webhook and SIEM export are future capabilities.
Read about NHI discovery

What you get

An inventory you can query, trust and hand to an auditor

The inventory is the foundation every other capability reads from — classification, ownership, credential security, posture and agent governance all start here.

Unified inventory

Search and filter every identity by type, environment, owner, lifecycle state and last use where the provider reports it

Graph-linked records

Every identity links to its owner, its credentials and the resources it can reach

Change history

Created, changed and deleted events with connector evidence and timestamps

Humans kept out

AWS console users and GitHub users of type User are excluded, so a person is never listed as a service account

Presence tracking

Identities that stop appearing in a sync are marked absent, not silently deleted

Exportable evidence

Evidence packages from the hash-chained audit trail, verifiable offline, for audits and incident response

Example

What discovery looks like when it finds something

A new identity is only interesting if the finding tells you why it matters. Every discovery finding answers the same nine questions.

HighNew identityNo ownerProduction

Unowned machine user discovered in a production account

Why
A machine user with an access key appeared in a production AWS account with no owner tag
What
aws-user/etl-runner-3 (service account) with one access key
Who
Owner unknown — no Owner, Team or ManagedBy tag, and nobody has assigned one
Where
AWS account data-prod · environment prod (from the connector)
How
Discovered by a sync; AWS reports its access key last used 2 hours ago, while the user itself reports no last use
Blast radius
Reach to 3 resources classified high impact · effective access, an upper bound
Recommendation
Assign an owner, confirm its purpose or retire it, move the workload to a role instead of a static key
Action
Assign owner · propose remediation for second-person approval
Evidence
IAM snapshot 2026-08-20 · access key metadata · sync diff #48213
Nine questions, source records attached. Missing evidence is shown as unknown.Illustrative finding · sample environment

See your identities discovered on a scoped connector.

See how TRUSTIVAN connects identity, credential, access, agent and action context into one control plane.