How to Review a System for Trust Boundaries
A structured checklist for evaluating where trust sits in a system, what is assumed, and where claims break down under scrutiny.
This framework is for reviewing any system that makes claims about governance, verification, evidence, or trust. It works for security platforms, AI agent systems, compliance tools, or any architecture where the question is: what can I actually verify, and what am I taking on faith?
Before you start
Gather the system's public documentation, architecture diagrams, threat model (if published), and any sample artifacts (receipts, reports, evidence bundles). If the system does not publish a threat model, that is itself a finding.
Step 1: Map the authority boundaries
Identify every entity that makes decisions in the system.
| Question | What you are looking for |
|---|---|
| Who decides if an action is allowed? | The authorization or policy layer |
| Who executes the action? | The runtime, agent, or tool |
| Who records what happened? | The logging, receipt, or evidence system |
| Who verifies the record? | The verification path (internal or external) |
If any of these are the same entity, note it. A system where the executor also records and verifies its own output has a weaker trust model than one where those roles are separated.
Example: In a typical AI agent platform, the answers might be: the policy layer decides (authorization), the LLM runtime executes (tool calls), the platform's receipt system records, and verification is internal-only. Noting that execution and recording are handled by the same platform — with no external verification path — reveals the trust model immediately.
Step 2: Identify the trust assumptions
For each boundary identified in Step 1, ask:
- What does this component assume about the others?
- What happens if that assumption is wrong?
- Can an external party check whether the assumption held?
Common trust assumptions to look for:
- Key distribution. The system assumes the verifier has the correct public key. How is the key distributed? Can it be rotated? Is there a certificate chain?
- Timestamp integrity. The system assumes timestamps are accurate. Are they self-asserted or from an external authority?
- Execution fidelity. The system assumes the runtime did what it was told. Is there execution evidence beyond the runtime's own report?
- Scope enforcement. The system assumes actions stayed within declared boundaries. Is scope enforced at runtime or only checked at the beginning?
Step 3: Trace a claim end-to-end
Pick one specific claim the system makes — for example, "this action was governed and produced a signed receipt."
Then trace the claim through the system:
- What triggered the action? (operator request, scheduled task, automated trigger)
- What approved it? (policy gate, manual approval, self-approval)
- What executed it? (which runtime, which tool, which environment)
- What was recorded? (receipt, log, evidence bundle)
- What can be verified? (signature, timestamp, inclusion proof, execution hash)
- What remains assumed? (runtime honesty, key integrity, scope enforcement)
The gap between what is claimed and what is verifiable is the trust surface.
Step 4: Test the failure path
Ask: what happens when this system fails?
- What happens if a policy gate is bypassed?
- What happens if the signing key is compromised?
- What happens if the timestamp authority is unavailable?
- What happens if execution produces no evidence?
- What happens if a receipt is disputed?
A system with clear failure modes and documented recovery paths is more trustworthy than one that only describes the happy path.
Step 5: Evaluate the proof artifacts
If the system produces proof artifacts (receipts, bundles, signed records), evaluate them:
| Property | Question |
|---|---|
| Portability | Can the artifact be verified outside the originating system? |
| Independence | Does verification require trusting the issuer? |
| Completeness | Does the artifact include everything needed to verify it, or does it reference external state? |
| Tamper evidence | Would modification of the artifact be detectable? |
| Time binding | Is the timestamp from an external authority or self-asserted? |
Step 6: Write the findings
Structure your findings as:
- What the system claims — the stated trust model
- What the system can prove — what is cryptographically or independently verifiable
- What the system assumes — trust assumptions that are not independently verifiable
- Where the gaps are — claims that exceed what the evidence supports
- What to watch — assumptions most likely to fail or be challenged
The principle
Every system has trust boundaries. The question is not whether they exist, but whether they are visible, narrow, and honestly stated. A system that publishes its trust assumptions is easier to trust than one that hides them behind confident claims.
See also: How to Scope a Governed AI Engagement — the scoping method for determining what is reviewable before a trust-boundary review begins.