---
title: Trust evidence
description: Expiring, typed evidence that policy can require — not a reputation score.
label: Trust evidence
---

Trust in Veefore is a set of **evidence records**, each with a type, an issuer,
a status and an expiry. It is not a number, and that is the point: a score of 72
tells an operator nothing they can act on, while "the security attestation
expired eleven days ago" tells them exactly what to do.

## Evidence types

| 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 has been completed |
| `COMPLIANCE_EVIDENCE` | A compliance control has been satisfied |
| `PUBLISHER_VERIFICATION` | The publisher of the agent has been 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`.

`EXPIRING` exists so there is a window in which you can act before enforcement
starts refusing. A policy requiring valid security attestation, with attestation
quietly lapsing overnight, is an outage you did not schedule.

## Recording evidence

```bash
curl -X POST https://veefore.example.com/v1/trust/evidence \
  -H "Authorization: Bearer $VEEFORE_API_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "agent_id": "agt_01JAV…",
    "type": "SECURITY_ATTESTATION",
    "issuer": "internal-security-review",
    "expires_at": "2027-04-01T00:00:00.000Z",
    "detail": { "review_id": "SEC-2026-118", "scope": "code and dependencies" }
  }'
```

Requires `trust:manage`, which `SECURITY_ADMIN` holds and `DEVELOPER` does not —
an agent's author should not be the one attesting that the agent is safe.

## Reading it

```http
GET /v1/trust/{agentId}
```

Returns the evidence summary and an explanation of what is present, what is
expiring, what has lapsed, and what a policy requiring each type would currently
decide.

## Using it in policy

Six fields are available to rules:

| Field | Type |
| --- | --- |
| `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 |

The `_valid` fields are `true` only when evidence of that type exists **and has
not expired**. Expiry is folded into the field, so a rule cannot accidentally
accept stale evidence.

```json
{
  "id": "rule-production-requires-attestation",
  "name": "Production needs valid security attestation",
  "priority": 880,
  "enabled": true,
  "when": {
    "kind": "group",
    "id": "g-prod-attestation",
    "operator": "and",
    "children": [
      {
        "kind": "condition",
        "id": "c-env-prod",
        "field": "environment.type",
        "operator": "eq",
        "value": "PRODUCTION"
      },
      {
        "kind": "condition",
        "id": "c-attestation",
        "field": "trust.security_attestation_valid",
        "operator": "is_false"
      }
    ]
  },
  "then": {
    "decision": "BLOCK",
    "reason": "A valid security attestation is required to act in production."
  }
}
```

Refused with `TRUST_EVIDENCE_INSUFFICIENT` when the pipeline's trust stage
determines required evidence is missing or expired.

Open incidents are also directly testable, which is a useful safety interlock:

```json
{
  "kind": "condition",
  "id": "c-active-incidents",
  "field": "trust.active_incidents",
  "operator": "gt",
  "value": 0
}
```

Pair that with `REQUIRE_APPROVAL` and an agent under active investigation needs a
human for everything until the incident is closed.

## Risk reads it too

`TRUST_EVIDENCE` is one of the thirteen risk signals. It fires when required
evidence is missing, expiring or expired, and contributes to the risk score — so
lapsed evidence raises risk even if no policy explicitly requires that type.

A single lapse therefore has two independent effects, which is intentional
defence in depth: the score rises, and any rule testing the `_valid` field flips.

## Trust and A2A

For agent-to-agent, trust evidence is how you decide whether a verified remote
agent is one you want to deal with. Passport verification proves *who* they are;
trust evidence informs *whether* you should. They answer different questions and
you generally want both.

## Related

:::cards

:::card Agent Passport | /concepts/passport
Where the trust block is published.
:::

:::card Risk engine | /concepts/risk
The `TRUST_EVIDENCE` signal.
:::

:::card A2A | /build/a2a
Trust evidence in the context that needs it most.
:::

:::card Trust API | /reference/api/trust
Read a summary, record evidence.
:::

:::