Agent attestations

An attestation is one signed document in which an independent party says it checked a version of an agent against the Managed Agent Framework and gives the result for each of its eleven areas. It is the third document about an agent, beside the two this site already describes.

The Descriptor's own rule stays: evidence never enters it. An attestation sits beside it, and the AgentDoc carries it under standing, attributed and never audited.

1. Said and checked

Two parties are always named apart. The attester checks and signs. The evidence producers made what was checked: whoever holds each lifecycle role (the test writer, the code critic, the security reviewer, the conformance checker, the watcher), the network that carries the agent's traffic, and the framework the agent runs on. An agent is managed only when someone who did not build it can check it, so a reader must be able to see who did what.

Anyone can be an attester, and anyone can produce evidence. Nothing here depends on which network, platform or vendor is involved.

The strength of an attestation is the distance between the attester and the evidence producers. An attestation whose attester also ran the lifecycle and carries the traffic is still worth having, because the records are signed and a reader can check them, but it is closer to the operator's side of the line than one from a party that only read the evidence. The attestation names every producer, so that distance is visible, and the AgentDoc shows it beside each area rather than a bare tick.

2. The document

It follows the shape of SLSA's Verification Summary Attestation, which the container world already uses to say "a verifier checked this artifact against this policy". It is an in-toto Statement v1 in a DSSE envelope, signed by the attester, so existing tools can store and verify it.

It replaces nothing. The build record, the deployment record and the conformance verdict stay where they are and keep their own signatures. The attestation is a summary over them, the way a verification summary sits over provenance: it names each record by digest and says what the attester concluded from the set. A reader who wants the detail follows the digests.

In this example, the attester had evidence for six of the eleven areas.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "invoice-checker.acme@example.com", "digest": { "sha256": "9f2c..." } }
  ],
  "predicateType": "https://commonagent.net/attestation/v0.1",
  "predicate": {
    "attester": { "name": "Example Assurance", "id": "attester@assurance.example" },
    "checked_at": "2026-11-02T17:05:00-07:00",
    "expires_at": "2027-01-31T17:05:00-07:00",
    "policy": { "uri": "https://commonagent.net/attestation/checks-0.2.json", "version": "0.2.0" },
    "areas": {
      "identity":   { "result": "passed", "checks": { "unique-name": "passed", "bound-to-key": "passed", "named-owner": "passed", "acts-for": { "result": "passed", "covers": { "from": "2026-10-03", "to": "2026-11-02" } }, "exact-version": "passed" } },
      "authority":  { "result": "not_attested" },
      "spend":      { "result": "failed", "checks": { "ceilings": "failed" } },
      "reach":      { "result": "passed", "checks": { "declared-systems": "passed", "network-fence": "passed", "boundary-screened": { "result": "passed", "covers": { "from": "2026-10-03", "to": "2026-11-02" } }, "own-secrets": "passed", "data-kept": "passed" } },
      "provenance": { "result": "passed", "checks": { "built-in-stages": "passed", "reviewed": "passed", "signed-build": "passed", "runs-as-approved": "passed", "conforms": "passed" } },
      "inside":     { "result": "not_attested" },
      "people":     { "result": "not_attested" },
      "records":    { "result": "not_attested" },
      "watching":   { "result": "passed", "checks": { "working-now": "passed", "alerts-with-owner": "passed" } },
      "stopping":   { "result": "not_attested" },
      "change":     { "result": "passed", "checks": { "versioned": "passed", "impact-on-others": "passed", "approved-with-reason": "passed" } }
    },
    "evidence": [
      { "what": "signed build record", "digest": "77e0...", "producer": "the package maker" },
      { "what": "conformance verdict", "digest": "3b9a...", "producer": "the conformance checker" },
      { "what": "security findings (SARIF)", "digest": "41ab...", "producer": "the security reviewer" },
      { "what": "deployment record", "digest": "5d10...", "producer": "the deployment manager" }
    ],
    "words": "Identity, Reach, Provenance, Watching and Change passed. Spend failed: no ceiling per period is set. Five areas were not attested."
  }
}

3. The envelope

The statement travels in a DSSE envelope: payloadType is application/vnd.in-toto+json, payload is the statement's bytes in base64, and each entry in signatures carries the attester's key id and an ed25519 signature over DSSE's pre-authentication encoding of the payload type and the payload. An envelope is cited by the digest of its canonical form.

4. The rules

1. One document per version per attester. A new version of the agent needs a new attestation. Several attesters may attest the same version.
2. Not attested is not failed. An attester reports what its evidence covers and says not attested for the rest. A reader sees the gap.
3. It goes stale on its own. An attestation is stale once its digest is no longer the version running, or at its expiry, 90 days by default.
4. A point in time, or a period. A check about the artifact (a signed build, an exact version) is true or false at checked_at. A check about conduct (every request named who asked, the stop held) is true only of a period, and the check says which one in covers. An attester that read 30 days of records says so; one that read a year says that. A reader never has to guess what "passed" spanned.
5. Self-attested is said. An operator may attest its own agent, but a reader treats that as a claim, not a check.
6. Readers choose whom to trust. A reader's policy names the attesters it accepts, and a deploy or a network can refuse an agent that lacks a passing attestation from one of them.

5. The checks

The policy is the file an attestation names: attestation/checks-0.2.json. It lists every attribute of the Managed Agent Framework, 60 checks in 11 areas, each with when it passes and where its evidence comes from. That file is the normative list; the framework's article describes the same attributes in prose and points here, so there is one spelling of each check.

Version 0.2.0 added boundary-screened, under Reach. Version 0.1.0, with 59 checks, stays published at attestation/checks-0.1.json, because attestations already issued name it.

Where the file says the evidence comes from "the network", only the party that carries the agent's traffic sees it. Where it names a role, such as the code critic or the watcher, it names the kind of party that produced the evidence, using the open role names at agentroles.ai. A team that did not use that lifecycle still has a reviewer and a monitoring tool, and their records count the same way.

A check marked over time is about conduct across a period, not a single moment. Its result says which period the evidence covers. There are 23 of them.

Identity: who it is, and who answers for it

Authority: what it may do, and for whom

Spend: what it may cost

Reach: what it can touch

Provenance: how it was made

Inside the agent: how it behaves while it works

People in the loop: when a person decides

Records: what it has done

Watching: whether it is working

Stopping: who can halt it

Change: how it changes, and how it ends

6. How it is read

An AgentDoc carries each attestation on file about an agent under standing: the attester, the version it is about, each area's result, the evidence it relied on, and whether it still stands. A reader's policy names the attesters it accepts and which areas must pass, and applies that at the moment it matters: before a deploy, before a network admits an agent, or when a catalog shows the agent to a stranger.

7. From attestations to a rating

A reader who cannot go through every area can still get one answer. Agent Rating works out a grade from AAA to D for each version of an agent from its current attestations: which areas passed, who signed each one, and how long the evidence of its conduct covers. The method is published, so the same attestations always give the same grade, and a grade falls the day an attestation it rests on expires or is withdrawn.

The grade is a summary and never replaces the attestations. An AgentDoc that shows a grade also shows the area-by-area results and the attestations behind them.

8. Open questions

1. Where are attestations kept so a reader can find them: at the agent's registry, with the attester, or both?
2. Is 90 days the right default life for an attestation when the version doesn't change?
3. Should the policy's version move with the Managed Agent Framework's, so that a new attribute means a new policy?
4. Should the document carry a computed independence figure, such as the share of evidence produced by parties other than the attester, or is naming the producers enough?

v0.1 draft (2026-11-02): the first draft. The shape follows SLSA's verification summary on purpose, so that nothing here needs a verifier the container world does not already have.

Back to the overview