NEW RESEARCH: Your Sandbox Is Made of Glass

Read

Trinitite

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.

live graphs joined

asset kinds, one list

call, either direction

Signed

trees for auditors

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.

tr.trace(id="support-bot")

one id · one tree

Policy graph

Identity graph

Assets

Decision lineage

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 tree

policy_graph

decision_lineage

nhi_binding

assets

Zero 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.

tr.guardian("refund").assign(identity="support-bot")

no manual mapping

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

GUARDIAN_ASSIGNED_TO_NHI

NHI_USES_ASSET

ASSET_GOVERNED_BY_GUARDIAN

Scopes

ASSET_MEMBER_OF_SCOPE

SCOPE_GOVERNED_BY_GUARDIAN

Incidents

INCIDENT_INVOKES_CLAUSE

INCIDENT_REPLAY_OF

People

PRINCIPAL_OWNED_ASSET

PRINCIPAL_RAN_CALL

Policy & controls

GUARDIAN_TRAINED_ON

MAPS_TO_CONTROL

COVERS_CLAUSE

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.

assets.py

python

# 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-guardian

tr.assets() — 14 kinds

mcp_server

swg_connector

cli_session

skill

connector

vendor

credential

chat_client

nhi_identity

guardian

policy

framework

test_suite

tool

tr.compliance().control("soc2:CC6.1")

coverageDepth: 2

One call returns the policy nodes, suites, and Guardians that cover a control — the evidence an auditor asks for, not a screenshot.

Compliance

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.

crosswalk.py

python

# "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"]  2

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.

who.py

python

# 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 through

tr.who(employee="alex@acme.com")

a person → what their AI touched

When 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.

verify.py

python

# 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 auditor

Filter 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.

logs.py

python

# 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

link.py

python

# 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.