Ownership & Lifecycle

Every machine has a human.Every agent credential has an end date.

Machines and agents cannot vouch for themselves. Trustivan attributes each identity to an accountable owner, tracks its lifecycle state from sync evidence, and flags the identities that stopped being used but kept their access.

AvailableM2 · Ownership & lifecycle

Owner from tags or a person · unknown is a first-class state

Lifecycle

Owned. Tracked. Retired.

Three states a non-human identity should pass through — and the evidence each one leaves behind for the next reviewer.

Owned

An accountable user or team for every identity — declared by a tag or a person, inferred where the evidence is weaker, unknown when nothing says

Tracked

A lifecycle state from discovery onward — active, inactive, stale, orphaned, quarantined — recomputed from each sync

Retired

Stale and orphaned identities quarantined in the platform and proposed for decommission, with the evidence kept

How it works

Owners from evidence, assigned by people

Who the tags name, which labels the workload carries, who a person assigned — ownership is a conclusion from evidence, marked declared, inferred or unknown, not a mandatory field someone filled in once.

Attribution

From “probably the platform team” to a named, accountable owner

Trustivan reads ownership from provider tags and labels — Owner and Contact as declared, Team or ManagedBy as inferred — and resolves it to a user or team in your organization. Where nothing resolves, a person can assign one. Unowned identities become findings, not a mystery.

  • Ownership signals ranked by strength: assigned by a person, declared by tag, inferred from a weaker tag or label.
  • A hint is not an owner: a tag naming a team that does not exist stays unresolved and visible.
  • Unknown owner is a state, with its own workflow — not a blank cell nobody filters for.
See the orphaned NHI use case
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
Dormancy

Access that is not used is risk without benefit

An identity that has not been used in 90 days still holds every permission it ever had. Trustivan marks an identity stale when its provider-reported last use passes your threshold — AWS reports it for roles — and never calls an identity unused when the provider simply does not say.

  • Last use where the provider reports it, and “not reported” everywhere else, never a guessed timestamp.
  • Inactive identity, active credential: a finding of its own, because the key still works.
  • Activity you submit counts: events sent through the ingestion API are weighed against staleness.
Certification

Reviewers certify or revoke from the evidence, not from a spreadsheet

A certification item carries the identity's effective access, its last use and its open findings, so a reviewer can certify or revoke. Every decision is recorded with the reviewer and the time — and a revoke records an instruction; it does not remove the access by itself.

  • Campaigns are dated questions to a named reviewer about a defined population.
  • One decision per item, with the audit record written automatically — no bulk decisions, by design.
  • Built in the API; the console screen for campaigns is a future capability.
Campaign console: future capability

What you get

Accountability you can measure, and prove

Ownership coverage becomes a number you can report — and the identities behind that number each carry their own evidence.

Owner coverage

Share of identities with a declared owner by environment, with the unowned count

Orphan detection

Identities whose owner no longer resolves, or never did, flagged with the ownership evidence

Staleness reports

Identities past your staleness threshold, from last use reported only by AWS — for roles, and for access keys

Certification records

Who certified or revoked what, and when — built in the API, console screen to come

Credential expiry

Expiring and expired credentials flagged against the identity and owner that answer for them

Lifecycle evidence

The history of every identity from first discovery to retirement, exportable for auditors

Example

The team moved on. The identity kept its access.

The most common lifecycle failure is not malice — it is ownership that still points at a team nobody maintains anymore.

HighOrphanedPrivilegedProduction

Owner unresolved; workload identity still bound to cluster-admin in production

Why
The service account’s owner label names a team that no longer exists in this organization, and it still holds cluster-admin in two namespaces
What
k8s/platform/deploy-runner (Kubernetes service account)
Who
Owner: unresolved — label team=release-eng matches no team · no owner assigned
Where
Kubernetes cluster prod-eu-1 · namespace platform
How
Bound by a ClusterRoleBinding; the deploy-runner Deployment and a nightly CronJob run as it
Blast radius
Cluster-admin on 2 namespaces · 1 token secret, counted and never read
Recommendation
Assign the Platform team, scope the binding to the namespaces it actually deploys
Action
Assign owner · propose the binding change for second-person approval
Evidence
RBAC snapshot 2026-08-20 · workload list · ownership record
Nine questions, source records attached. Missing evidence is shown as unknown.Illustrative finding · sample environment

Put a name on every machine identity.

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