# Trust model and evidence limits

Source: https://www.testifysec.com/docs/concepts/trust-model

What signed evidence proves, how to evaluate agent-fabricated evidence, and the trust boundaries between collection, identity, policy, enforcement, and delivery.

Trust comes from checking specific claims against explicit authorities and protected boundaries. A signature is one part of that process. It is not a truth detector.

 

## Can an agent fabricate the evidence?

 

**Yes, if it controls an accepted evidence producer or can use that producer's signing authority to sign false statements.** A valid signature can establish who signed particular bytes and whether those bytes changed. It cannot establish that every statement was true.

 

For evidence that must be independent of an agent, use a collection environment the agent cannot freely modify. Protect the required test, the collector, its signing authority, and the policy that decides which evidence counts. Require the expected producer and the code or artifact bindings needed by the workflow.

 

An agent-supplied report is input to evaluate. Its polished wording, a claimed test pass, a process name, or a recorded model name is not independent execution proof. A permissive policy that accepts any signer or any successful command does not establish that the intended test ran.

 

![A developer or agent supplies a change. A separately controlled environment runs the required check and signs its observations. The verifier checks signer, subject binding, and policy. If the author controls the accepted producer or signing authority, the independence assumption fails.](https://www.testifysec.com/media/docs/generated/evidence-boundary.svg)

**Separate the author from the trusted check.** A developer or agent supplies a change. A separately controlled environment runs the required check and signs its observations. The verifier checks signer, subject binding, and policy. If the author controls the accepted producer or signing authority, the independence assumption fails.

**Diagram source (Mermaid)**

```mermaid
flowchart TB
  A[Developer or agent supplies a change] --> T
  subgraph INDEPENDENT[Separately controlled execution]
    T[Required test and protected inputs] --> C[Trusted evidence producer]
    C --> S[Protected signing authority]
  end
  S -->|Signed observations| V[Verify signer and subject binding]
  P[Policy controlled by authorized actors] --> V
  V --> R[Scoped decision]
```

 

## Separate the claims

 

| Record or check | What a reviewer can conclude | What remains outside that conclusion |
| --- | --- | --- |
| Verified signature | The accepted signing identity signed these exact bytes under the checked trust rules. | The truth or completeness of the producer's observations. |
| Execution observation | A named collector recorded the activity its instrumentation could observe. | Activity outside its coverage or protection against a compromised collector. |
| Subject or commit binding | The evidence or decision is associated with the required subject when that binding is verified. | That a useful test was performed, unless the policy also checks that requirement. |
| Policy evaluation | The supplied evidence satisfied or failed the selected requirements for the bounded request. | All possible security properties or later changes to the environment. |
| Gate acceptance | The configured admission requirements allowed this push through this gate. | Bypass routes, downstream delivery, or the repository's later state. |
| Technical-control mapping | The result is related to the stated control assessment. | Whole-framework compliance, certification, or authorization. |

 

## Review each trust boundary

 

### Collection

 

Identify what the collector can observe and what the agent can change. Review the runner, workflow definition, test inputs, instrumentation coverage, and access to the signing mechanism. Collection on an agent-controlled workstation and collection on a protected runner are different trust postures.

 

### Identity and signing

 

Verify the certificate or key against the intended roots and identity constraints. Keep evidence producer, observed agent context, policy signer, policy publisher, activation actor, push signer, and delivery observer separate.

 

A stored authenticated session establishes control of that session at its stated assurance level. It does not prove that a human was present for a particular action. Read the actual deployed signing or approval ceremony before making a stronger claim.

 

### Policy and authorization

 

Identify the exact signed policy release and repository assignment. Review who can publish policy, activate an assignment, and authorize an override. These are distinct permissions.

 

Require a durable decision with the expected bindings. An unavailable evaluator or missing decision provenance is not a passing result. An override of a valid denial must remain distinguishable from a policy pass; it cannot repair missing provenance.

 

### Enforcement and delivery

 

Check where the gate is mandatory and which routes can bypass it. Protect the upstream Git host accordingly. Read delivery status from a delivery observation, not from a policy pass. Interpret a receipt using the fields its deployed version actually signs.

 

## Test the boundary with negative cases

 

Use a controlled evaluation environment and an authorized test repository. These are acceptance scenarios, not claims that every existing configuration already enforces every condition.

 

| Scenario | Requirement to evaluate |
| --- | --- |
| Change the bytes after signing. | Signature verification rejects the modified envelope. |
| Supply correctly signed evidence from an unaccepted producer. | The identity or trust constraint rejects it. |
| Reuse evidence for another commit or artifact. | The required subject binding rejects it. |
| Omit a required result or supply a failing result. | The selected policy refuses the incomplete or failed requirements. |
| Make the decision service unavailable. | The gate does not convert missing provenance into acceptance. |
| Try an unauthorized policy change or override. | The corresponding authorization boundary rejects it. |
| Push around the gate. | Upstream repository protections prevent the bypass you intended to prohibit. |
| Let an accepted producer sign an invented report. | This exposes a producer-trust failure; cryptography alone cannot distinguish the lie. |

 

## What a security review should request

 

Request a representative signed evidence envelope, the policy and its trusted signer, the repository assignment, the bounded decision, and any applicable delivery record. Verify them against the intended trust configuration. Review the running version and the status of the features your workflow depends on.

 

Also review administrator authority, root-key handling, credential revocation, evidence retention, backups, and recovery for the chosen deployment. Cryptographic verification and operational security answer different parts of the trust question.

 

Continue with [system architecture](https://www.testifysec.com/docs/concepts/architecture), [CI/lock trust configuration](https://www.testifysec.com/docs/cilock/trust), and [Pushgate security coverage](https://www.testifysec.com/docs/pushgate/security-coverage).