Architecture / Decision records

ADR 0007: Trust evidence

Typed, expiring, attributable evidence that policy can require — rather than a reputation score nobody can act on.

#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.

Statuses: VALID, EXPIRING, EXPIRED, REVOKED.

Policy sees booleans with expiry folded in.

textCopy
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.

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

#Related

• Trust evidence
• Risk engine
• Incidents
• Policy fields