ContactBook a demo

Identity Governance

IGA stopped at the humans.The identities didn’t.

Joiner, mover, leaver worked for people. Your machines and agents outnumber them, were never onboarded, rarely move and almost never leave. Trustivan brings governance discipline to non-human identities: discover, own, review, contain — with evidence for each step.

AvailableCertification console: future capabilityM1 audit · M2 ownership & lifecycle · M9 access grants
Book a demoExplore NHI Governance

Works alongside your IGA for people · governs the population it was never built for

The need

Governance built for people, applied to a population that isn’t

Four assumptions traditional identity governance makes — and why each one breaks the moment the identity is a service account, a workload or an agent.

  • Identity

    IGA assumesEvery identity belongs to a person who can be asked about it

    For machines and agentsService accounts and agents have owners only if someone wrote one down — and those people change teams and leave

  • Lifecycle

    IGA assumesJoiner, mover and leaver events arrive from HR

    For machines and agentsMachines are created by pipelines and deleted by nobody; no HR event ever fires for them

  • Access

    IGA assumesAccess is requested, approved and provisioned

    For machines and agentsMost machine access is granted by infrastructure code and inherited through roles nobody reviews

  • Certification

    IGA assumesAnnual certification campaigns keep entitlements honest

    For machines and agentsAn agent’s permissions change with a config commit; a yearly review cannot keep up

How Trustivan maps to it

Discover. Own. Review. Contain. Prove.

The verbs your governance program already uses — executed on the identities it could not see, with the evidence model doing the paperwork.

Discover & own

Start with an inventory that includes the identities IGA never saw

Connectors inventory roles, machine users, access keys, App installations, ServiceAccounts and AppRoles across AWS, GitHub, Kubernetes and Vault, and resolve an owner for each from provider tags and labels. Where nothing says, the owner is unknown — a state with its own finding, not a blank cell.

  • Every identity typed and placed in an environment, with its credentials and grants attached.
  • Owners declared, inferred or unknown, and assignable by a person when the tags are silent.
  • Unowned and privileged identities raise findings of their own, so a gap is never a quiet default.
See Ownership & Lifecycle
Review & certify

Certification that asks a named reviewer about a defined population

A campaign puts a dated question to a named reviewer about a set of identities, credentials, tools or teams. Nobody answers a campaign they opened, and an item left unanswered expires rather than passing. Campaigns are built in the API; the console screen is a future capability.

  • No bulk decisions: each item is decided on its own — the absence is the control.
  • A revoke records an instruction, which somebody still carries out at the provider.
  • Coverage is honest: a campaign that has asked nothing reports no coverage, not 100%.
Console screen: future capability
Access grants

Time-bounded access, approved by someone else

An agent that needs elevated access gets a grant, not a standing role: at most seven days, approved by a person who did not request it, and read by the runtime gate as a fact. Grant expiry runs from an authenticated endpoint rather than a schedule. There is no request workflow for creating identities.

  • Built into the platform with organizations, teams, roles and a hash-chained audit trail — available today.
  • Seven days at most, and nobody approves their own request.
  • Decommission is proposed, not executed: a second person approves; nothing runs at a provider today.
See Decommission Tracking
Evidence

Every governance decision leaves a record an auditor can read

Ownership changes, exception approvals, certification decisions and remediation proposals are written to an append-only audit trail, hash-chained per tenant so an alteration is detectable. When a control is tested, the evidence is already assembled — and where evidence is missing, the record says unknown.

  • Per-identity history from first discovery to decommission.
  • Evidence packages exported from the same records and verifiable offline.
  • No invented metrics: coverage numbers link to the identities behind them.
Why risk must be explainable
HighOrphaned identityLong-lived credential

Orphaned service identity with reachable production data

Why
Orphaned service account still holds active production credentials
What
svc-billing-export (service identity)
Who
Owner unknown — no owner tag and no assigned owner
Where
cloud account prod-core · region eu-west-1
How
Long-lived access key (age 611 days), still active, on a machine IAM user
Blast radius
2 production databases, 1 backup bucket, 4 downstream services
Recommendation
Assign owner, rotate to short-lived credential, scope role to export-only
Action
Propose remediation · assign owner · quarantine in platform
Evidence
AWS IAM sync 2026-08-19 · access-key metadata · owner tag absent
Evidence before claims — when evidence is missing, Trustivan shows unknown, never a fabricated score.Illustrative finding · sample environment

Outcomes

What a governed non-human population looks like

Not a new dashboard — a set of numbers you can stand behind, each one backed by the identities and records it counts.

Owner coverage you can report

Owners for production identities — declared, inferred or unknown — with the unowned count always visible

Reviewed access

Certification campaigns that put dated questions to named reviewers — built in the API, console screen to come

Orphans contained

Orphaned and stale identities found, quarantined in the platform and proposed for decommission with evidence

Grants with an end

Agent access granted for at most seven days, approved by someone other than the requester

Audit-ready evidence

Ownership, exception and remediation records in a hash-chained audit trail, exportable as evidence

Agents included

AI agents governed under the same model as service accounts — owner, lifecycle, findings, access

Related use cases

Where governance gaps turn into incidents

Each scenario walks through why it happens, how Trustivan helps and what the evidence looks like.

All use cases

Related needs

Governance is the foundation of the other programs

Risk management prioritizes governed identities; agent security governs a new population; access intelligence shows what they can reach.

All solutions

Govern the identities IGA never saw.

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

Book a demo