The identity graph is the data structure every Trustivan capability reads from and writes to. This article explains how it is built: what the nodes and edges are, where they come from, how evidence is attached, how tenancy and time are handled, and what we deliberately chose not to do. Capabilities are labelled as available or not built throughout.
Why a graph
The questions that matter about a machine identity are questions about relationships. Who is accountable for it is an edge to a human. What can it reach is a path through credentials, services and resources. What is the blast radius is the set of nodes reachable from it. A table of identities with columns cannot answer these without joins that quietly encode assumptions; a graph makes the relationships first-class and makes each one carry its own evidence.
Nodes
The node types mirror the relationship model used across the platform:
| Node | Examples | Primary source |
|---|---|---|
| Human | users and teams | The organization’s own users and teams |
| Identity | IAM roles, service accounts, GitHub Apps, Kubernetes ServiceAccounts, agents | AWS IAM, GitHub, Kubernetes, HashiCorp Vault |
| Credential | access keys on machine users (metadata only) | AWS IAM |
| Service | cloud APIs, databases, internal APIs | Connector configuration |
| Resource | repositories, clusters, workloads, Vault instances, MCP servers | GitHub, Kubernetes, Vault and MCP connectors |
| Action | read, write, delete, deploy, approve | Activity submitted through the ingestion API |
| Tool | tools exposed by MCP servers | Model Context Protocol connector (Available) |
Every node is keyed by tenant, connector and the source system’s own identifier. The same real-world workload seen by two connectors — an AWS role and the Kubernetes ServiceAccount that assumes it — stays two records. An operator can confirm a link between them, and a canonical identity is computed from confirmed links; nothing is merged, by design.
Edges
Edges are typed and directional — fifteen kinds, among them owns, authenticates with, has permission, accesses, assumes and belongs to — and each is attributed to the connector that produced it. Two properties of every edge matter more than its type.
Observed or inferred. An observed edge was read directly from a source: a role binding, a key attached to a user, an OAuth grant. An inferred edge was derived: this identity probably reaches that bucket because the role it holds allows it and the bucket policy does not deny it. Inferred edges carry a confidence and the rule that produced them, and they are rendered differently so that nobody mistakes a derivation for a fact. Effective access, transitive reach and blast radius are available today; a reach is observed only when every hop is, and it is an upper bound, because AWS managed policy documents are not read and Deny statements and conditions are not evaluated.
Evidence. Every edge — and every node — carries an evidence envelope.
The evidence envelope
An evidence envelope answers how do we know this without requiring anyone to open another tool:
- Source: the connector and the source system.
- Object: the source system’s identifier for the record.
- Snapshot: when the record was read, and the connector run that read it.
- Attributes: the normalized fields, plus the provider’s payload with credential material redacted.
- Derivation (inferred edges only): the rule and inputs that produced the edge.
When a finding is shown — an orphaned service identity with a long-lived key and reachable production data, say — each of its nine fields (why, what, who, where, how, blast radius, recommendation, action, evidence) resolves to envelopes on specific nodes and edges. When a factor has no envelope, the finding says unknown. We do not average over missing data.
Time
The graph keeps its history rather than overwriting it. Each connector run reconciles what it saw: nodes and edges carry first seen and last seen timestamps, and a relationship that disappears from a complete run is marked absent rather than deleted — while a partial run marks it unknown and concludes nothing. Nothing is ever deleted, which is what allows a question like this identity could reach that bucket until Tuesday to be answered in an incident review.
Tenancy
Every node, edge and envelope is partitioned by tenant at the storage layer, and every query is scoped by tenant before anything else is evaluated. There is no cross-tenant query path in the platform’s API, including for Trustivan staff. Connector credentials are held per tenant in an isolated secret store and are used only by that tenant’s sync jobs.
What the graph does not store
The graph stores credential metadata — type, age, last rotation, where it is attached — and never credential values. Connectors are read-only and do not retrieve secret material; where a source API would return a secret value, the connector does not request it. This is a deliberate narrowing of scope: Trustivan needs to know that a key exists, how old it is and what it unlocks, not what the key is.
How agents extend the graph
Agents are identities in the graph, typed as AI agents, with a profile recording their autonomy. A tool is a node with its own provenance, discovered from its MCP server. Which tools an agent may use is a tool entitlement declared by an operator, because no connector observes an agent using a tool, and there is no agent-to-agent edge, by design. Modelling agents this way means agent findings inherit everything the graph already knows — owner, credentials, effective access — instead of living in a separate inventory. No connector discovers an agent, and no screen registers one.
The same facts feed runtime action authorization, which is available today: the decision for an action request is computed from the requesting identity, its credential, the tool’s entitlement and effect, the resource’s impact and the agent’s autonomy. The purpose attached to a request is recorded for the investigator; no rule decides on it.
Limitations we know about
- Some sources do not expose last-use data; dormancy is unknown for those identities by design.
- Audit-log retention in the source bounds how far back creator and modifier evidence can go.
- The same object seen by two connectors is linked only when an operator confirms it; identity resolution has an API and no console screen yet.
- Inferred edges are only as good as the permission model of the source; effective access is an upper bound, because managed policy documents, Deny statements and conditions are not evaluated.
The design goal throughout is simple to state: a responder, an owner or an auditor should be able to take any claim the platform makes and walk it back to the records that support it. Relationships become evidence when each one can show where it came from.