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.