# Can You Trust the Evidence an Agent Gives You?

Source: https://www.testifysec.com/blog/compliance-evidence-fiction/

Author: TestifySec

Published: 2026-03-20

Updated: 2026-10-06

A signature cannot make fabricated evidence true. Start with the producer, the execution boundary, and the exact claim being verified.

Editorial update · October 6, 2026

Revised by TestifySec Editorial to remove unsupported outcome claims and explain the current product and trust boundaries. The original publication date and URL are preserved.

- [Current TestifySec docs →](https://www.testifysec.com/docs)
- [Trust architecture →](https://www.testifysec.com/docs/cilock/trust)

The question I hear most often is straightforward: what stops an agent from making up the evidence?

 

A signature alone does not. If an agent can write any statement and obtain an accepted signature for it, the result can be a well-attributed lie. The useful question is what the evidence producer actually observed and what the agent could change.

 

## Start with the producer

 

Separate the actor doing the work from the component observing it. Decide which execution environment and producer identities the verifier will trust. Then examine whether the code under test can alter that producer, its inputs, or its signing authority.

 

A local capture controlled by the same actor as the work has different assurance from a protected runner. Naming an agent in metadata does not authenticate it. Capturing a command also does not imply complete observation of everything that happened outside the capture boundary.

 

## Bind the result to the work

 

A useful test record identifies the exact commit or artifact it examined, the test and configuration, and the outcome. A result for yesterday’s artifact is not evidence for today’s artifact merely because the filenames match.

 

Keep failed results, missing evidence, and capture limitations visible. A report saying “passed” is only useful if the verifier knows what was tested and whether the expected producer supplied the result.

 

## Verify before accepting

 

Verification must check the expected identity, signed statement, artifact binding, and configured requirements. The check needs to run at an enforced decision point.

 

CI/lock captures the work. Pushgate checks the push at the Git boundary. The platform manages multiple gates and reuses evidence for technical control mappings. Capture, policy publication, gate activation, push acceptance, and downstream delivery remain separate events.

 

## Map the evidence without enlarging the claim

 

A recovery rehearsal may show that a defined workload was restored under stated conditions. It does not establish that every recovery scenario works. A validation scan may support a vulnerability remediation claim. It does not prove that the application has no vulnerabilities.

 

The platform’s mapping should explain which requirement the result supports, what was outside the test, and when a new result is needed. An agent may help find or explain the evidence; its explanation should link back to the supporting record.

 

## What signatures and timestamps contribute

 

A valid signature can establish attribution and detect alteration under the configured trust model. Trusted time evidence can support a verification decision about when signed data existed. Neither establishes that the underlying observation was truthful or that an entire control was satisfied.

 

The trust architecture must say what happens when the producer, signer, or execution environment is compromised. Open-source code can make those mechanisms inspectable; it is not a guarantee that a particular deployment is secure.

 

## Five questions to ask

 

1. Who produced this record, and how was that identity authenticated?
 2. What work and artifact does it describe?
 3. Could the actor doing the work change the observation or signing path?
 4. What exactly did the verifier check, and where was the decision enforced?
 5. What would a failed, missing, stale, or mismatched result look like?

 

Ask for a walkthrough that includes those negative cases. Read the [trust architecture](https://www.testifysec.com/docs/cilock/trust) and the [Pushgate decision boundary](https://www.testifysec.com/docs/pushgate/trust-architecture) alongside the demonstration. That is how to evaluate the evidence instead of relying on the confidence of the agent presenting it.