Governance Graph
Ask one question. Get the whole tree back.
Your AI governance lives in a dozen places: identities, Guardians, policies, controls, tools, incidents, and the people who own them. The governance graph joins them into one map, so you can start from any node and see everything it connects to, in a single call.
One id, one tree
Stop stitching answers together by hand
“Which identity enforces which policy for which control?” used to mean jumping between your identity system, your policy rules, your Guardians, and your compliance mappings, then piecing the answer together.
Anchor on any node and the tree comes back already joined, with a note of exactly which parts of your estate it pulled from.
How it works
Four live graphs, one traversal surface
This is a data layer, not another proxy. It joins your Policy Knowledge Graph, your signed Decision-Lineage graph, your identity bindings, and your asset inventory, queried in parallel and merged into one normalized tree.
An anchor that lives in only one graph just returns an empty slice from the others. Every response carries a provenance block so you always know what joined it.
tr.trace(id="support-bot")
four graphs · one treeZero maintenance
The graph builds itself
You never draw this graph. The actions you already take (assigning a Guardian, binding an MCP tool, opening an incident) are caught and projected into edges for you. Assign a Guardian to an agent and the link is in the tree before you refresh.
The edges are derived, so they can be rebuilt from the source of truth any time, no drift, no stale mapping to babysit.
Do the work you already do. The edges are projected for you — and can be rebuilt any time with tr.graph().rebuild().
What connects to what
Every link in your estate, in one vocabulary
The graph speaks one set of node kinds and edge kinds across the whole estate. That shared vocabulary is what lets a single walk cross from a person, to an agent, to a policy, to a control, to an asset, without you knowing which system holds which node.
Identities & assets
Scopes
Incidents
People
Policy & controls
Unified inventory
Every asset your agents touch, one list
Fourteen kinds of asset (from MCP servers to CLI sessions to skills to credentials) used to mean fourteen different lookups. Now it is one call, one shared id vocabulary, and the same ids the graph nodes use.
# One inventory across every asset kind (no 14-way fan-out).
for a in tr.assets(kind="mcp_server", status="active", limit=100):
print(a.graphNodeId, a.label, a.guardianId)
# mcp_server:srv_abc support-tools MCP refund-guardianCompliance
Prove a control is covered
Anchor a control like SOC 2 CC6.1 and walk it back to the policy nodes, test suites, and Guardians that cover it, with a coverage depth. It is the reverse of asking a Guardian what it covers, and it is the exact evidence an auditor wants.
# "Which policies, suites, and Guardians cover SOC 2 CC6.1?"
for row in tr.compliance().control("soc2:CC6.1"):
print(row.controlId, row.guardianIds, row.coverageDepth)
# soc2:CC6.1 ["refund-guardian","pii-guardian"] 2One call returns the policy nodes, suites, and Guardians that cover a control: the evidence an auditor asks for, not a screenshot.
Human accountability
Trace a person, not just an agent
Agents don’t own themselves. People do. The graph adds a person to the map, so you can trace an employee to the agents they own and the Guardians their AI ran calls through, then one hop further to every asset and policy those touched.
When something goes wrong, the first question, “whose is this?”, has an answer.
# Trace a person to everything their AI touched.
who = tr.who(employee="alex@acme.com")
print(who.nhis()) # agents Alex owns
print(who.assets()) # assets those agents reached
print(who.guardians) # Guardians Alex's AI ran calls throughWhen an agent misbehaves, the first question is "whose is it?" The graph answers it, and shows every asset and policy that agent reached.
Trust & investigation
Signed where it counts, and it makes your logs smarter
Ask for verification and any tree that reaches a decision comes back with a KMS-signed attestation an auditor can check independently, the same proof surface behind deterministic replay.
# Add depth, a kinds filter, and a signed tree for an auditor.
tree = tr.trace(
id="decision_88ab",
depth=4,
kinds=["decision", "model", "dataset"],
verify=True,
)
print(tree.attestation.signature_status) # "valid" -> hand to auditorFilter audit logs by a control or an asset. The graph resolves what that means, which policy nodes, which identities, so the query you actually want is one call.
# Audit logs, graph-aware: filter by a control AND an asset.
logs = tr.results(filter={
"control_id": "soc2:CC6.1",
"asset_id": "mcp_server:srv_abc",
"limit": 50,
})
# graph resolves control -> policy nodes and asset -> identities for you# The graph auto-wires most edges. Link the rest by hand:
tr.identity("support-bot").link(asset="mcp_server:srv_abc")
tr.guardian("refund-guardian").governs(asset="mcp_server:srv_abc")Most edges auto-wire; when you want to record a relationship by hand, link it directly.
Definition
What is a governance graph?
A governance graph is a single map of how your AI governance is wired. It connects the identities your agents use, the Guardians that watch them, your policy rules, your compliance controls, every tool and MCP server they touch, the decisions they make, and the people who own them.
It is not a document store or a search index. It answers relationship questions: who enforces what, on which asset, under which rule, owned by whom, from any starting point, in either direction.
Capabilities
Everything, connected
Start from anything
Anchor on an agent, a Guardian, a policy, a control, an MCP server, an incident, or a person, and walk the tree in either direction.
One join, not a dozen lookups
Policy, decision-lineage, identity, and asset graphs are queried in parallel and merged into one answer, with a provenance stamp of what it pulled from.
Blast radius on demand
Before you retire a Guardian or change a policy, trace it and see every agent, asset, control, and person that depends on it.
Coverage you can prove
Anchor a SOC 2 or NIST control and get the policies, suites, and Guardians that cover it, with a coverage depth, not a guess.
People, not just agents
Trace a real employee to the agents they own and the Guardians their AI ran calls through, accountability that reaches a human.
Signed where it counts
When a tree reaches a decision, attach the KMS-signed attestation so an auditor can re-run it and get the same bytes.
Use cases
What teams ask the graph
Prove a control is covered
An auditor asks “show me what enforces access control.” Anchor the control, hand them the policies, suites, and Guardians mapped to it.
Blast radius before a change
About to retire a Guardian or edit a policy? Trace it first and see every agent, asset, control, and person that depends on it.
Investigate an incident fast
Start from the incident and walk to the policy clauses it invoked, the scenario it replays, and the identities and assets involved.
Answer “whose agent is this?”
Start from a misbehaving agent and walk back to the person who owns it, and forward to every asset and policy it reached.
Find the reachable identities
Anchor a sensitive MCP server or tool and walk back to every identity that can reach it and every Guardian standing in the way.
Smarter audit-log queries
Filter your logs by a control or an asset; the graph resolves which policy nodes and identities that means and returns the matching events.
FAQ
Governance graph, answered.
What is a governance graph?
A governance graph is one connected map of how your AI governance is wired: the identities your agents use, the Guardians that watch them, the policy rules, the compliance controls, the tools and MCP servers they touch, the decisions they make, and the people who own them. Trinitite joins four live graphs (policy, decision-lineage, identity-binding, and assets) so you can start from any one of those and get the connected tree back in a single call, in either direction.
Is this a knowledge base or RAG system for my documents?
No. It is not document search or retrieval. It maps how your governance is connected: which identity enforces which policy, for which control, on which asset, owned by which person. It is the god’s-view of your agent estate, not a place to store files for an LLM to read.
How is this different from querying my audit logs?
Audit logs tell you what happened. The governance graph tells you how everything is connected before and after it happens, and it makes your logs smarter. You can filter logs by a control or an asset, and Trinitite walks the graph to resolve which policy nodes and identities that means, then returns the matching events in one query.
Do I have to build or maintain the graph myself?
No. The graph is projected automatically from your live governance data. When you assign a Guardian to an agent, bind a Guardian to an MCP tool, or open an incident, the connecting edges appear on their own. You can also link nodes by hand when you want to record a relationship explicitly, and you can rebuild every edge from the source-of-truth tables at any time.
What kinds of things can I anchor on?
Any node in the estate: an NHI or service identity, a Guardian, a policy document or policy node, a compliance control, a test scenario/suite/run, an incident, a decision, a scope, a person (user), or any of the 14 asset kinds (MCP server, CLI session, skill, connector, vendor, credential, and more). The endpoint routes your anchor to the right underlying graph automatically.
Can I trust the tree in front of a regulator?
Yes. When a subtree spans decision-lineage nodes and you ask for it, the response carries a KMS-signed attestation envelope. An auditor can verify it independently and re-run the decision to get the same bytes, the same proof surface behind deterministic replay and immutable audit logs.
Ready when you are
See your whole estate as one tree.
Book a walkthrough and trace one of your own agents, from the person who owns it to the control it enforces, in a single call.