Home / Core concepts

Trust evidence

Expiring, typed evidence that policy can require — not a reputation score.

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

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

bashCopy
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

httpCopy
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:

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.

jsonCopy
{
  "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:

jsonCopy
{
  "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