---
title: 'ADR 0007: Trust evidence'
description: Typed, expiring, attributable evidence that policy can require — rather than a reputation score nobody can act on.
label: '0007 Trust evidence'
---

## Context

Policy sometimes needs to depend on something outside the request: has this
agent been security reviewed, is the owning organization verified, is there an
open incident.

The conventional shape is a trust score. One number, computed from inputs,
comparable across agents, easy to threshold.

It is also useless at the moment it matters. "Blocked: trust score 61" tells an
operator nothing they can act on, and tells the person affected nothing at all.

## Decision

**Typed evidence records**, each with an issuer, a status and an **expiry**.

| Type | Attests |
| --- | --- |
| `IDENTITY_VERIFICATION` | The agent's identity has been verified |
| `ORGANIZATION_VERIFICATION` | The owning organization has been verified |
| `SECURITY_ATTESTATION` | A security review or scan completed |
| `COMPLIANCE_EVIDENCE` | A compliance control was satisfied |
| `PUBLISHER_VERIFICATION` | The publisher was verified |
| `PROTOCOL_COMPLIANCE` | The agent conforms to a protocol specification |
| `OPERATIONAL_HISTORY` | A record of operating cleanly over a period |
| `INCIDENT_HISTORY` | Involvement in past incidents |

Statuses: `VALID`, `EXPIRING`, `EXPIRED`, `REVOKED`.

**Policy sees booleans with expiry folded in.**

```text
trust.identity_verified              boolean
trust.organization_verified          boolean
trust.security_attestation_valid     boolean
trust.protocol_compliance_valid      boolean
trust.active_incidents               number
trust.expired_evidence_count         number
```

A `_valid` field is `true` only when evidence of that type exists **and has not
expired**. There is no way for a rule to accidentally accept stale evidence,
because expiry is not a separate field a rule could forget to check.

**`EXPIRING` exists as a status** so there is a window to act before enforcement
starts refusing.

**Risk reads it independently.** `TRUST_EVIDENCE` is one of the thirteen
signals, so lapsed evidence raises the risk score even where no policy rule
requires that type.

**`trust:manage` belongs to `SECURITY_ADMIN`, not `DEVELOPER`.**

## Alternatives

**A trust score.** One number, thresholdable, comparable.

Unactionable at the point of refusal, and it makes every rule testing it change
behaviour silently when the scoring weights are retuned. A rule written against
`trust.score >= 70` means something different after a retune; a rule written
against `trust.security_attestation_valid` does not.

**Non-expiring evidence.** Simpler: record it once, it stays true. A security
review from two years ago is not evidence the agent is safe today, and the
absence of expiry means nothing ever prompts a renewal.

**Expiry as a separate field rules must check.** More flexible — a rule could
deliberately accept recently-expired evidence. It also means every rule must
remember to check it, and the failure mode of forgetting is accepting stale
evidence, which is exactly the thing this is for.

**Let `DEVELOPER` record evidence.** Convenient. An agent's author attesting
that the agent is safe is not independent attestation. The separation is
deliberate and occasionally inconvenient.

**Derive trust entirely from observed behaviour.** No manual records, no
expiries, no process. That is what the risk engine already does, and it answers
a different question: risk is "is this request unusual", trust is "has anyone
checked this agent". Both are useful and neither substitutes.

## Consequences

**Someone has to record evidence, and renew it.** There is no automatic
population. A policy requiring valid security attestation, with attestation
quietly lapsing overnight, is an outage you did not schedule.

Mitigated three ways: the `EXPIRING` status, the `TRUST_EVIDENCE` risk signal,
and a `doctor` finding. All three fire before the cliff.

**Evidence lapse changes decisions.** By design, and it is the consequence
people are least prepared for. A rule that has allowed traffic for six months
starts refusing because an attestation expired, and nothing about the agent or
the policy changed.

The `EXPIRING` window is the answer, and quarterly renewal is in
[Operate it](/journey/operate).

**A fixed field set, not arbitrary types.** Adding a new evidence type is a code
change — it goes in `TRUST_EVIDENCE_TYPES` and gets a corresponding policy field
if it needs one. Deliberate: an open set would mean policy fields that exist in
one deployment and not another.

**Two independent effects from one lapse.** The risk score rises *and* any rule
testing the `_valid` field flips. That is intentional defence in depth, and it
means a lapse is visible even in a deployment with no rule that requires that
evidence type.

**`trust.active_incidents` is the most useful field, and it is not evidence.**
It is current state, exposed through the same namespace because it answers the
same kind of question. A rule testing it means opening an incident
automatically puts an agent behind human approval — with no policy edit under
pressure. [→ Incidents](/operate/incidents)

## Related

- [Trust evidence](/concepts/trust)
- [Risk engine](/concepts/risk)
- [Incidents](/operate/incidents)
- [Policy fields](/reference/policy-fields)