Public-release candidateBundle 1.0-rc.4Independent review pending

AI Trust Graph

Graph-based, evidence-driven assurance for connected AI systems.

AI Trust Graph is an open methodology that models connected AI environments as evidence-linked graphs of identities, agents, models, tools, data, infrastructure and providers — and the relationships between them — so that assurance conclusions stay bounded by what the evidence can actually support.

Illustrative connected AI system graphA synthetic example. A human instructs an agent. The agent uses a model, retrieves data and invokes a tool. The model is hosted by a provider. The tool acts as an identity. That identity reaches a business system across a trust boundary, but whether it holds authority there is marked UNKNOWN.TRUST BOUNDARYinstructsinvokesusesretrieveshosted byacts asauthority: UNKNOWNHumanAgentToolDataModelIdentityProviderBusiness system
Synthetic Illustrative only. Graph topology alone does not prove authority, invocation, reachability or exploitability.

The problem

AI systems are no longer isolated models.

  1. Models connect to agents.
  2. Agents invoke tools.
  3. Tools operate through identities.
  4. Identities cross boundaries.
  5. Actions may reach consequential systems.

Risk can emerge through the relationships between them.

Relationships describe what may be possible; on their own they do not establish exploitation. A topological connection is not automatically an exploitable path.

Source: Artifact #1 — Manifesto

The reasoning chain

From what exists to what can be defended.

Objects create a system description. Relationships establish how the objects interact. Paths combine relationships under conditions. Authority and influence explain how consequences can be caused. Evidence and controls determine what can be concluded.

The Core Conceptual Model calls this chain the intellectual spine of the methodology.

    1. Objects

    What exists?

    Objects and system boundary.

    1. Relationships

    How is it connected?

    Typed directional relationships.

    1. Conditions

    What must be true?

    Preconditions and state.

    1. Paths

    What can happen next?

    Reachability and path analysis.

    1. Authority and Influence

    Who or what can cause it?

    Authority, influence and actionability.

    1. Consequence

    Why does it matter?

    Target criticality and consequence.

    1. Controls

    What interrupts it?

    Control breakpoint and resilience.

    1. Evidence

    2. Decision

    What can we defend?

    Evidence, confidence and accountable decision.

Source: stage names and order from the reasoning chain in Artifact #2 — Core Conceptual Model §0.10; questions and concepts from the same section’s theory map, whose final row covers both Evidence and Decision.

A separate lifecycle: the 13-phase Assessment Methodology

The reasoning chain belongs to the Core Conceptual Model. Assessment fieldwork is governed separately by Artifact #7, which defines the controlled fieldwork lifecycle and gates without redefining upstream semantics.

Source: Artifact #7 — Assessment Methodology; METHODOLOGY_MANIFEST §1

  1. Initiate
  2. Scope
  3. Discover
  4. Model
  5. Evidence
  6. Controls
  7. Paths
  8. Maturity
  9. Scoring
  10. Findings
  11. Decisions
  12. Report
  13. Reassess

Six domains

Six coordinated lenses over one graph.

The domains are coordinated assessment lenses over one graph. They are not separate products and should not maintain incompatible definitions, evidence grades or scoring assumptions. Each has twelve canonical controls and six maturity capabilities.

  • D1ATG-DIS-001…012

    Discovery and AIBOM

    Establish measurable estate, ownership, dependencies and shadow AI.

    Maturity capabilities
    1. D1.1 Discovery scope and source coverage
    2. D1.2 Canonical inventory and ownership
    3. D1.3 Shadow AI and unmanaged use
    4. D1.4 AIBOM and dependency lineage
    5. D1.5 Unknown, orphan and lifecycle management
    6. D1.6 Discovery evidence and assurance
  • D2ATG-TRU-001…012

    Trust and Privilege Paths

    Model cloud and AI trust, identity inheritance and attacker-relevant paths.

    Maturity capabilities
    1. D2.1 Trust relationship representation
    2. D2.2 Identity and privilege path analysis
    3. D2.3 Boundary and provider trust
    4. D2.4 Path identification and prioritization
    5. D2.5 Control breakpoint analysis
    6. D2.6 Trust graph quality and governance
  • D3ATG-AUT-001…012

    Authority Governance

    Define and review effective access, inference, approval and action.

    Maturity capabilities
    1. D3.1 Authority inventory and taxonomy
    2. D3.2 Delegation and identity context
    3. D3.3 Human approval and oversight
    4. D3.4 Authority amplification control
    5. D3.5 Revocation and containment
    6. D3.6 Authority decision governance
  • D4ATG-VAL-001…012

    AI Security Validation

    Test architecture and controls against realistic scenarios.

    Maturity capabilities
    1. D4.1 Validation strategy and scope
    2. D4.2 Threat modeling and path hypotheses
    3. D4.3 Rules of engagement and safety
    4. D4.4 Control effectiveness testing
    5. D4.5 Finding quality and closure
    6. D4.6 Validation assurance and independence
  • D5ATG-GOV-001…012

    AI Governance and Assurance

    Connect ownership, risk tier, policy, obligations and evidence.

    Maturity capabilities
    1. D5.1 Strategy, policy and risk appetite
    2. D5.2 Use-case intake and tiering
    3. D5.3 Decision rights and accountability
    4. D5.4 Applicability and obligations
    5. D5.5 Exceptions and risk acceptance
    6. D5.6 Assurance, reporting and literacy
  • D6ATG-RES-001…012

    Operational Resilience

    Prepare for failure, compromise, containment and recovery.

    Maturity capabilities
    1. D6.1 Observability and attribution
    2. D6.2 Detection and triage
    3. D6.3 Containment and kill mechanisms
    4. D6.4 Recovery, rollback and compensation
    5. D6.5 Incident reconstruction and evidence
    6. D6.6 Exercises, learning and resilience governance

Source: purposes from Artifact #2 §8.1; capabilities from Artifact #3 — Maturity Model; control IDs from Artifact #5 — Master Control Library.

Authority

Access is not authority.

Each of these is a separate claim. Each needs its own evidence, and none is silently inferred from another.

  • Can connect
  • Can authenticate
  • Can access
  • Can invoke
  • Can modify
  • Can transact

Illustration of distinct assertions only — not a canonical sequence, ladder or state machine.

The capability definition, its network reachability, granted authority and actual invocation are different concepts and require different relationships.

Canonical authority classes

  • Observe
  • Read
  • Retrieve
  • Infer
  • Recommend
  • Approve
  • Execute
  • Modify
  • Delete
  • Disclose
  • Transact

Authority classes describe the kind of consequence an entity can cause. They are not maturity levels and should not be ranked without considering target, scope, conditions and criticality.

Source: Artifact #2 §5.2

Evidence-bounded conclusions

UNKNOWN stays UNKNOWN.

Insufficient evidence does not silently become a favourable — or an adverse — conclusion. UNKNOWN remains visible until sufficient evidence and accountable review resolve the material assertion.

  • UNKNOWNis notSafe
  • UNKNOWNis notFailed
  • UNKNOWNis notZero risk
  • UNKNOWNis notN/A

UNKNOWN is not Not Tested.

They are distinct non-numeric result states with different meanings.

UNKNOWN

The material state remains unresolved because evidence is absent, insufficient or materially conflicting.

Numeric treatment No numeric value.

Reporting treatment Included in uncertainty and evidence-gap counts.

Not Tested

Testing required for a stronger conclusion was not performed.

Numeric treatment No numeric value for effectiveness.

Reporting treatment May retain a design score if separately supported.

Neither may be silently converted into a fabricated effectiveness result. Evidence grade E0 (no evidence) can support either, according to context: The only defensible conclusion is UNKNOWN or Not Tested.

Source: meanings from Artifact #6 — Evidence Model §0.5, §1.1; numeric and reporting treatment from Artifact #4 — Scoring Framework §0.5.

UNKNOWN is not zero, weak, safe or effective.

Distinct non-numeric result states

  • Not Assessed
  • UNKNOWN
  • Inconclusive
  • Not Tested
  • Not Applicable

Each state has its own numeric and reporting treatment. They must never be silently collapsed into one another, into a score, or into a pass/fail. AI Trust Graph deliberately produces no single overall trust score.

Source: Artifact #4 §0.5

Control breakpoints

Where can a material path be interrupted?

A control breakpoint is a node, relationship or boundary where an effective control can materially stop, constrain, detect or contain a path. Alternate and residual paths must still be checked.

Illustrate an effective control that can…
  1. Human
  2. Agent
  3. Identity
  4. Tool
  5. API
  6. Sensitive action

Stop. Progression past the breakpoint is blocked.

Constrain. Progression continues only within narrower scope or conditions.

Detect. Progression is observed and raises a signal for response.

Contain. Downstream effect is isolated or limited.

Synthetic Plain-language illustration of where an effective control can stop, constrain, detect or contain progression. It is not a real system, and it does not show that any step is authorized, invoked, reachable or exploitable.

Path validation state

  • Candidate
  • Topological
  • Plausible
  • Validated
  • Exploitable
  • Controlled
  • Invalidated

Path role

  • Primary
  • Alternate
  • Residual

Validation state and role are orthogonal dimensions and are not collapsed into one state machine.

Source: Artifact #2 §1.8, §6.3, §6.6

Evidence model

Six grades of evidentiary support.

A grade measures how strongly a source supports a precisely stated assertion — not desirability, safety or compliance. A high grade can confirm an adverse state.

  1. E0

    No evidence

    No source is available or the supplied item cannot be linked to the assertion.

    The only defensible conclusion is UNKNOWN or Not Tested. E0 is not evidence that the control is absent.

  2. E1

    Inference or uncorroborated signal

    A hypothesis is derived from incomplete, indirect, automated or unverified information.

    Can prioritize investigation and create candidate graph assertions, but cannot establish implementation or operating effectiveness.

  3. E2

    Attestation

    An accountable person states that a condition or practice exists.

    Supports claimed practice and context; needs corroboration for material technical claims.

  4. E3

    Approved documentary evidence

    A governed document records approved design, policy, architecture, procedure, contract or decision.

    Can support design intent and governance state. It does not alone prove actual configuration, runtime behavior or sustained operation.

  5. E4

    Corroborated technical evidence

    Technical evidence from authoritative sources is supported by an independent source, consistent observation or reproducible inspection.

    Can support implementation or operation within observed scope when current, relevant and representative.

  6. E5

    Direct technical and representative evidence

    Current direct technical evidence is combined with a representative test or operating record that demonstrates the claimed behavior under stated conditions.

    May support verified effectiveness or adaptive operation, but only for the tested scope, period and conditions.

Grade is not sufficiency. Meeting the grade minimum is necessary but not sufficient; relevance, scope, currentness, representativeness, conflict status and an approved reviewer decision still govern.

Grade is its own quantity. Evidence grade is never added to control effectiveness, severity, maturity or risk as if they were the same quantity.

Source: Artifact #6 — Evidence Model §1.1–§1.8. The full sufficiency rules are deliberately not summarized here — read them at source.

The structure that carries the model

Domains
6
Canonical controls
72
Maturity capabilities
36
Maturity levels
M1–M5
Evidence grades
E0–E5

Maturity is cumulative, evidence-gated and not an average of control scores.

Public review

This methodology is meant to be challenged.

  • Challenge the assumptions.
  • Examine the graph semantics.
  • Inspect the evidence rules.
  • Report inconsistencies.
  • Contribute through GitHub.