Product update

The connector contract and identity graph search

How identities enter Trustivan — one read-only connector contract with a sync lifecycle and evidence on every record — and a graph you can walk for reach, paths and blast radius.

Trustivan SecuritySeptember 12, 20265 min read

This note describes the connector contract and the identity graph as they are built today. Labels follow our legend: Available means built and running in the platform, Future capability means not built yet, and Not built marks what is absent by design.

What exists

The connector contract — Available

Every integration implements one contract, and a connector sync is the only way an identity enters the inventory. A connector authenticates, enumerates the objects it is allowed to see, normalizes them into the identity model, attaches evidence to every record and reports whether its enumeration was complete. Persistence, reconciliation and lifecycle belong to the platform, never to the connector, so an identity has the same shape whether it came from AWS IAM, GitHub, Kubernetes or HashiCorp Vault. The fifth connector, Model Context Protocol, discovers tool servers and their tools rather than identities. The full connector list, with honest status per connector, is on the integrations page.

The contract defines:

  • A sync lifecycle. Pending → running → succeeded, partially failed or failed, with counts per run. Status is derived, never asserted, so a run cannot report success over errors. Runs are manual, initial or scheduled — the scheduler is off until you enable it — and reconciliation is idempotent, so re-running a sync never duplicates an identity.
  • Read-only collection. A connector reads; the contract has no operation that changes anything at a provider. Outbound calls go only to allow-listed HTTPS hosts, never to private or loopback addresses.
  • Evidence on every record. Each record carries the connector that observed it, the provider’s identifier, the observation time, the sync run and the provider payload with credential material redacted. When a source does not report an attribute — most do not report last use — the platform shows unknown rather than inferring a value.
  • Absence only from a complete run. Only a successful, complete enumeration may conclude that something is gone. A throttled or partial run marks what it did not see as unknown and changes no lifecycle state.

Identity search and graph traversal — Available

Search the inventory by name prefix or exact provider identifier, sort by type, lifecycle state, ownership, last seen or last use, and open any identity into the graph. From there the platform answers four questions over the relationships the connectors observed:

neighbourhood   what this identity connects to, within a bounded number of hops
path            the shortest observed route between two nodes
effective access every resource it can reach, with the route to each
blast radius    what is reachable, counted by sensitivity

Every edge is attributed to the connector that produced it, and a reach is reported as the actual edges behind it — never collapsed into a grant the identity does not hold. Effective access is an upper bound: AWS managed policy documents are not read, and Deny statements and conditions are not evaluated.

Connector health — Available

Each connector reports its health — healthy, degraded, unreachable, unauthorized or misconfigured — from a check that proves both that its credentials work and that they may read what it is about to read, alongside its sync history. Creating, enabling, disabling and changing a connector are written to the audit trail.

What is not built

  • More connectors. Azure, Google Cloud, Entra ID, Okta, GitLab, Jenkins and SaaS platforms have no connector; they are planned, not built.
  • A credential scanner. Credential metadata arrives with each sync, and age, rotation, expiry, sharing and exposure findings are available. Exposures are reported to the platform through its ingestion API; no scanner ships.
  • Agent discovery — Not built. 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

The contract and the graph are the foundation the runtime gate stands on. The runtime gate is built: an agent runtime presents its credential, thirteen deny-by-default rules decide ALLOW, CHALLENGE or DENY, and the decision is recorded immutably. It enforces wherever the agent runtime calls it.

Keep reading

Product updateSep 12, 2026·5 min read

Classification, ownership and lifecycle, as built

How Trustivan types each identity, records who owns it and on whose word, and tracks where it is in its life — with evidence behind every value and unknown shown as unknown.

Read more
BlogJul 28, 2026·7 min read

Shadow AI is an identity problem

Blocking AI tools does not stop shadow AI. Agents show up in the identity layer as new principals, OAuth grants and tool bindings — which is exactly where you can govern them.

Read more

See the evidence behind every identity.

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