This note describes how classification, ownership and lifecycle work in the Trustivan platform today. Labels follow our legend: Available is built and running in the platform, Future capability is not built yet, and Not built marks what is absent by design.
What exists
Classification from the source — Available
Every connector maps what a provider reports onto one closed set of non-human identity types, and keeps the provider’s own type as evidence. A few examples:
- AWS IAM role → iam_role
- AWS access key → a credential, never an identity
- GitHub App → oauth_application
- Kubernetes ServiceAccount → kubernetes_service_account
- Vault machine identity → service_account
When a provider reports something no rule recognizes, the identity is typed unknown and its raw type is retained. We would rather show a gap than guess. Nothing in authorization, risk or lifecycle reads the provider’s raw vocabulary.
Ownership with its source — Available
Ownership resolves to a user or a team in your organization, and it has three states: owned, unresolved — the provider names someone your organization does not have, such as a tag reading owner: platform-team — and unowned. Ownership arrives from provider tags and labels where a connector reports them, or is assigned by a person; each carries its source and confidence.
An assignment made by a person is never overwritten by a sync, and a provider reporting no owner never clears one. Only an operator can assert that an identity is unowned. Every ownership change is written to the audit trail.
Lifecycle states — Available
The inventory records where an identity is in its life: discovered, active, inactive and decommissioned follow what the connectors observe, and quarantined is set by an operator. An identity is decommissioned only when a complete, successful sync no longer finds it — never from a failed or partial run — and neither quarantined nor decommissioned is ever left automatically. Stale and orphaned are conclusions, so they are reported as findings rather than written into the inventory.
Last use is reported only by AWS: for roles, and for access keys unless the connector’s per-key lookup is turned off. Everywhere else it is unknown, never unused.
Risk with evidence — Available
Risk for an identity is built from named contributions, each traced to a finding and the evidence behind it, with a history of how it has changed. Blast radius is a tally by sensitivity rather than a score, and resources nobody has classified are counted as unclassified, never as low.
Also available
- Findings for unowned, stale, and inactive-with-active-credential identities, each with its evidence.
- Credential inventory: metadata linked to its identity, with age, rotation, expiry, sharing and exposure findings. Exposures are reported through the ingestion API.
- Effective access, as an upper bound computed on the graph.
- Model Context Protocol connector, discovering tool servers and their tools.
Future capability
- Least privilege from usage. Comparing effective access with what an identity actually uses needs permission-usage facts nothing collects today.
Not built
- No agent discovery. No connector discovers an agent, and no screen registers one. That is by design; what an operator declares is which tools an agent is entitled to use.
Runtime authorization — Available
Ownership and lifecycle are what the runtime gate stands on. The runtime gate is built: an agent runtime presents its credential, thirteen deny-by-default rules decide, and the decision is recorded. An action that needs elevated access can be backed by an access grant, approved by someone other than the person who requested it.
Known limitations
- Types come from the connector’s mapping; there is no manual reclassification.
- Owner suggestions from audit logs, commit history or CODEOWNERS, and attestation requests, are not built. Certification campaigns exist as an API with no console screen yet.
- Most sources do not report last use, so most lifecycle evidence of use is unknown by design.