# AgentPass — V0.1 Specification

**Version:** 0.1.0
**Date:** 3 May 2026
**Status:** Draft. For sharpening with Vera (GPT-5.5 second-opinion CLI) and Alfred before publication.
**Editors:** Workloft.ai LTD
**License:** This specification is licensed under Apache 2.0; the reference implementation under Apache 2.0.

## Abstract

AgentPass is a Verifiable Credential profile that enables a counterparty to verify in real-time that an AI agent is currently authorised to perform a specific action, in good audit-history standing, and capable of the action it's about to take. It composes W3C Verifiable Credentials Data Model 2.0, W3C Decentralized Identifiers (DIDs), Google AP2 V0.1 mandate primitives, and a Workloft-originated standing-claim and federation-discovery pattern. AgentPass is designed for institutional environments where AI agents act as counterparties in regulated workflows.

## Status of this document

This is an early draft (V0.1) intended as a strategic flag-plant. The spec has not been formally submitted to any standards body. Workloft.ai LTD intends to submit V0.1 to the Linux Foundation Agent2Agent Special Interest Group as a candidate companion specification to A2A v1.0, and to engage the W3C Credentials Community Group on AgentPass as a Verifiable Credential profile.

Comments and contributions are welcomed at the public repository (location TBD on Alfred name decision: github.com/workloft/agentpass or gitlab.com/workloft/agentpass).

## Terminology

The terms **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, and **MAY** are to be interpreted as described in [RFC 2119].

- **Agent** — an autonomous or semi-autonomous AI system that performs actions on behalf of an Operator.
- **Operator** — the institution that deploys, governs, and is accountable for an Agent.
- **Counterparty** — a party (institution, regulator, auditor, individual, another Agent) that interacts with an Agent and needs to verify its standing.
- **AgentPass document** — a signed Verifiable Credential conveying claims about an Agent's identity, mandate, standing, capabilities, and reputation at a point in time.
- **Verification authority** — an HTTP service operated by an Operator that responds to AgentPass verification queries from Counterparties.
- **Audit chain anchor** — a cryptographic reference to a public timestamping authority (e.g. Bitcoin block hash via OpenTimestamps) committing the Operator's audit log state at a given time.

## 1. Document structure

An AgentPass document is a JSON-LD document conforming to the W3C Verifiable Credentials Data Model 2.0, with type `AgentPass` and a Workloft-defined claims schema. The document is signed using Data Integrity Proof with the `eddsa-jcs-2022` cryptosuite.

### 1.1 Skeleton

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/security/data-integrity/v2",
    "https://agentpass.ai/v1/context.jsonld"
  ],
  "type": ["VerifiableCredential", "AgentPass"],
  "id": "urn:uuid:...",
  "issuer": "did:web:operator.example.com",
  "validFrom": "2026-05-03T08:00:00Z",
  "validUntil": "2026-05-03T08:15:00Z",
  "credentialSubject": {
    "id": "did:web:operator.example.com:agents:w4-drafter",
    "agent": { ... },
    "mandate": { ... },
    "standing": { ... },
    "capabilities": { ... },
    "reputation": { ... }
  },
  "credentialStatus": {
    "id": "https://operator.example.com/.well-known/agentpass/status/...",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "12345",
    "statusListCredential": "https://operator.example.com/.well-known/agentpass/status/list"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-05-03T08:00:00Z",
    "verificationMethod": "did:web:operator.example.com#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}
```

### 1.2 Validity period

AgentPass documents **SHOULD** have a validity window between 5 and 60 minutes (`validUntil - validFrom`). Implementations **MUST** reject documents where `validUntil` is more than 24 hours after `validFrom`. Short windows reduce replay-attack surface and ensure standing claims are fresh.

### 1.3 Identifiers

- `id` — UUID-based credential identifier; **MUST** be unique per issued AgentPass.
- `issuer` — the Operator's DID. **MUST** resolve to a valid `did:web` document with a verification method matching the proof's `verificationMethod`.
- `credentialSubject.id` — the Agent's DID, scoped under the Operator's DID using the path-based DID resolution pattern (e.g. `did:web:operator.example.com:agents:w4-drafter`).

## 2. The claims

### 2.1 `agent`

Agent identity and chain-of-custody:

```json
"agent": {
  "displayName": "W4 Regulatory Reporting Drafter",
  "createdAt": "2026-04-15T10:00:00Z",
  "agentType": "Drafter",
  "operatorBindingProof": "did:web:operator.example.com#proof-..."
}
```

- `agentType` enum: `Orchestrator`, `Executor`, `Advisor`, `Monitor`, `Drafter`, `Librarian`, `Custom`.
- `operatorBindingProof` references a separately-signed proof in the Operator's DID document binding this Agent's DID to the Operator's DID.

### 2.2 `mandate`

Current authorisation, scoped per AP2 V0.1:

```json
"mandate": {
  "id": "ap2:mandate:c5d89...",
  "type": "IntentMandate",
  "scope": ["draft_naic_schedule_narrative", "draft_oid_disclosure_narrative"],
  "dataClasses": ["operator_atlas_life_only"],
  "validFrom": "2026-05-01T00:00:00Z",
  "validUntil": "2026-08-01T00:00:00Z",
  "verifierUrl": "https://operator.example.com/.well-known/ap2/verify"
}
```

Verifiers **SHOULD** call `verifierUrl` to confirm the mandate is currently valid (not revoked, not superseded). The `mandate.id` references an AP2-issued mandate that lives independently of the AgentPass document.

### 2.3 `standing`

The novel part of AgentPass. Describes the Agent's audit-history posture:

```json
"standing": {
  "auditChainStatus": "intact",
  "lastAnchorRef": "btc:block:889234:tx:8a3c8e1f...",
  "lastAnchorAt": "2026-05-03T07:45:00Z",
  "operatingDays": 73,
  "violations": [],
  "verifiedBy": [
    {
      "verifier": "did:web:workloft.ai:sentinel",
      "attestedAt": "2026-05-03T07:45:00Z",
      "attestation": "z..."
    }
  ]
}
```

- `auditChainStatus` enum: `intact` (no gaps detected), `degraded` (one or more gaps in audit-anchor cadence), `broken` (audit-chain integrity check failed).
- `lastAnchorRef` references a public timestamping authority commitment. Format prefixes: `btc:block:N:tx:H` for Bitcoin/OpenTimestamps; `algo:round:N` for Algorand; `eth:block:N:tx:H` for Ethereum.
- `operatingDays` is the number of days the Agent has been deployed (for reputation purposes).
- `violations` is an array of revocation events; empty array means clean record.
- `verifiedBy` is an array of independent verifier attestations. The Operator **MAY** include zero or more third-party verifier attestations.

Counterparties **MUST** verify the `lastAnchorRef` against the named public timestamping authority before treating the standing claim as cryptographically valid.

### 2.4 `capabilities`

Capability advertisement extending W3C Agent Card:

```json
"capabilities": {
  "actions": ["draft_naic_schedule_narrative", "draft_oid_disclosure_narrative"],
  "dataClasses": ["operator_atlas_life_only"],
  "writeAccess": [],
  "humanGates": ["countersign_required_pre_submission"],
  "agentCardRef": "https://operator.example.com/.well-known/agent-card/w4-drafter.json"
}
```

- `actions` — the set of named action types the Agent is configured to perform. Action names are operator-defined strings; verifiers compare against expected action.
- `humanGates` — named human-in-the-loop checkpoints required before any non-reversible output. **MUST** be enumerated explicitly.

### 2.5 `reputation`

Track-record claims. V0.1 supports self-attested and counterparty-attested claims:

```json
"reputation": {
  "documentsProduced": 47,
  "officerCountersigned": 47,
  "regulatorOutcomes": [],
  "thirdPartyEndorsements": [
    {
      "endorser": "did:web:counterparty.example.com",
      "endorsementType": "successful_interaction",
      "interactionId": "ap2:cart:abc123",
      "issuedAt": "2026-04-20T14:00:00Z",
      "proof": "z..."
    }
  ]
}
```

V1.0 will extend `reputation` with third-party-attested claims (auditors, regulators, independent verifiers).

### 2.6 `proof`

W3C Data Integrity Proof using `eddsa-jcs-2022`:

```json
"proof": {
  "type": "DataIntegrityProof",
  "cryptosuite": "eddsa-jcs-2022",
  "created": "2026-05-03T08:00:00Z",
  "verificationMethod": "did:web:operator.example.com#key-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "z..."
}
```

Implementations **MUST** support `eddsa-jcs-2022` as the baseline cryptosuite. Implementations **MAY** support additional cryptosuites (e.g. `ecdsa-jcs-2026`).

## 3. Verification flow

A Counterparty verifies an AgentPass against an intended action and data class.

### 3.1 Local verification

The Counterparty performs the following checks **before** any external network calls:

1. The document is well-formed JSON-LD with the AgentPass type.
2. The proof signature is valid against the public key referenced in the issuer's `did:web` document.
3. `validFrom` ≤ now ≤ `validUntil`.
4. `mandate.scope` includes the intended action, and `mandate.dataClasses` includes the intended data class.
5. `standing.auditChainStatus` is `intact`.
6. `capabilities.actions` includes the intended action.
7. `violations` is empty.

If any local check fails, the Counterparty **MUST** reject the AgentPass and not proceed with the interaction.

### 3.2 Anchor verification

The Counterparty **MUST** verify the audit-chain anchor against the named public timestamping authority. For Bitcoin/OpenTimestamps anchors, this means querying a Bitcoin node (or a trusted Bitcoin-node API) for the block hash at the specified height and confirming the transaction's commitment matches the standing claim's Merkle root.

Counterparties **MAY** cache anchor verifications for up to 24 hours.

### 3.3 Mandate freshness check

The Counterparty **SHOULD** call `mandate.verifierUrl` with the mandate ID to confirm the mandate has not been revoked since issuance.

### 3.4 Authority query (federated mode)

In federated deployments, the Counterparty **MAY** also call the Operator's AgentPass verification authority to obtain a real-time standing assertion:

```
POST https://operator.example.com/.well-known/agentpass/verify
Content-Type: application/json

{
  "agentpass": <full_document>,
  "intendedAction": "draft_naic_schedule_narrative",
  "intendedDataClass": "operator_atlas_life_only"
}

→ Response (200):
{
  "verified": true,
  "checks": {
    "identitySignatureValid": true,
    "mandateInScope": true,
    "mandateUnexpired": true,
    "mandateNotRevoked": true,
    "auditChainIntact": true,
    "auditChainAnchorRecent": true,
    "anchorVerifiedOnPublicChain": true,
    "capabilityIncludes": true,
    "noViolations": true
  },
  "freshnessAt": "2026-05-03T08:00:01Z",
  "anchorVerification": {
    "publicChain": "bitcoin",
    "block": 889234,
    "verifiedAt": "2026-05-03T08:00:01Z"
  }
}
```

If the authority server is unavailable, the Counterparty **MUST** fall back to local verification (3.1) plus anchor verification (3.2). Local + anchor verification is sufficient on its own; the authority query is an additional, real-time freshness check.

## 4. Federation discovery

Operators **MUST** publish a discovery document at `https://<operator-domain>/.well-known/agentpass/authority.json`:

```json
{
  "operator": "did:web:operator.example.com",
  "agentpassVersion": "0.1",
  "authorityUrl": "https://operator.example.com/.well-known/agentpass/verify",
  "statusListUrl": "https://operator.example.com/.well-known/agentpass/status/list",
  "supportedAnchorChains": ["bitcoin", "algorand"],
  "publicKeyJwks": [...]
}
```

Counterparties resolve discovery from the issuer's domain, then proceed with verification.

## 5. Revocation

AgentPass uses W3C Status List 2021 for revocation. Each AgentPass document includes a `credentialStatus` field referencing a position in the Operator's revocation list. Counterparties **MUST** check the status list before treating the document as valid.

Operators **MAY** revoke an AgentPass for: mandate revocation, agent decommissioning, audit-chain breach, security incident, governance violation. Revocations **MUST** be reflected in the status list within 60 seconds of the triggering event.

## 6. Security considerations

- **Replay attacks** — short validity windows (5–60 min) mitigate; counterparties **MUST** reject expired documents.
- **Operator key compromise** — handled via `did:web` key rotation; old AgentPass documents signed under compromised keys become invalid retroactively when the verification method is removed from the DID document.
- **Audit-chain anchor forgery** — public timestamping authority chosen for cryptographic integrity (Bitcoin's hash chain has > 15 years of resistance). Counterparties **SHOULD** verify against multiple independent chains for high-stakes interactions.
- **Reputation manipulation** — third-party endorsements **MUST** be cryptographically signed by the endorser. Self-attested reputation is verifiable but not independently meaningful.
- **Federation MITM** — TLS required for all `.well-known` endpoints; `did:web` documents **MUST** be served over HTTPS.

## 7. Privacy considerations

- **Information leakage** — AgentPass documents reveal operating metadata (operatingDays, documentsProduced) that may be sensitive. Operators **SHOULD** consider whether to publish reputation claims or keep them private.
- **Linkability** — repeated AgentPass issuance creates a verifiable trail. For privacy-sensitive contexts, Operators **MAY** issue zero-knowledge versions of standing claims (V1.0 future work).
- **Counterparty observability** — verification authority query logs reveal which Counterparties verified which AgentPasses. Operators **SHOULD** treat these logs as confidential.

## 8. References

- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/)
- [W3C Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-1.0/)
- [W3C Data Integrity v1.0](https://www.w3.org/TR/vc-data-integrity/)
- [W3C Status List 2021](https://www.w3.org/TR/vc-status-list/)
- [Google Agent2Agent (A2A) v1.0](https://github.com/a2aproject/a2a-spec)
- [Google AP2 V0.1](https://google-research.github.io/ap2/)
- [OpenTimestamps](https://opentimestamps.org/)
- [Five Eyes joint guidance on agentic AI services, 1 May 2026](https://cyberscoop.com/cisa-nsa-five-eyes-guidance-secure-deployment-ai-agents/)
- [RFC 2119 Key words](https://www.rfc-editor.org/rfc/rfc2119)

## Appendix A — Vera stress-test brief (to dispatch once OpenRouter restored)

> Read /home/workloft/strategy/agentpass-spec-v0.1.md and /home/workloft/strategy/agentpass-concept.html. Stress-test the spec:
>
> 1. **Conformance to W3C VC Data Model 2.0** — does the AgentPass document validate against the VC schema, or are there fields/structures that violate the model?
> 2. **Federation pattern soundness** — is the `.well-known/agentpass/authority.json` discovery pattern actually deployable across heterogeneous operator stacks, or are there security/operational issues I'm not seeing?
> 3. **Anchor verification feasibility** — is requiring counterparties to verify Bitcoin block-hash anchors realistic, or will it break adoption due to the operational complexity of running Bitcoin nodes / trusting third-party APIs?
> 4. **Revocation latency** — 60-second revocation propagation is aggressive. Is it achievable in practice, and what are the failure modes?
> 5. **Privacy considerations** — what privacy issues am I underweighting? In particular: linkability of verifications, operator metadata leakage, counterparty observability.
> 6. **Strategic positioning** — re-read the concept doc. Is "MCP-scale" a defensible claim, or is AgentPass actually a niche institutional protocol that won't reach the breadth of MCP?
> 7. **Naming** — AgentPass vs Open Counterparty Protocol vs Agent Standing Protocol. From a positioning/distribution perspective, which is strongest?
>
> Be sharp. Don't validate. ~800–1500 words. Structured markdown response with one section per topic above.

## Appendix B — Worked example

End-to-end interaction: Operator (did:web:aeon.example.com) deploys a W4 Regulatory Reporting Drafter agent. The Drafter generates a draft NAIC schedule narrative. The Drafter requests upload access to AM Best's intake portal (the Counterparty).

1. **AgentPass issuance.** Aeon's authority service generates an AgentPass document at 08:00Z, signed with Aeon's key, valid until 08:15Z.
2. **Presentation.** The Drafter presents the AgentPass to AM Best's intake portal, along with the document it intends to upload, and the intended action `submit_naic_schedule_narrative`.
3. **AM Best local verification.** AM Best's verifier checks signature against `did:web:aeon.example.com` → valid. Mandate scope includes `draft_naic_schedule_narrative` → matches. Audit chain is `intact`. Anchor reference points to Bitcoin block 889234. No violations.
4. **AM Best anchor verification.** AM Best queries a Bitcoin node for block 889234, confirms the standing-claim Merkle root is committed. Anchor verified.
5. **AM Best authority query.** AM Best calls `https://aeon.example.com/.well-known/agentpass/verify` with the document and intended action. Authority returns `verified: true`.
6. **Submission accepted.** AM Best logs the AgentPass document and the verification result into their own audit trail. Submission proceeds.
7. **Officer countersign.** Aeon's named officer countersigns the submitted document via Aeon's signed-link countersign mechanism (separate from AgentPass).
8. **Final state.** AM Best now has cryptographic evidence — independently verifiable from any external party — that the submission was produced by an Agent in good standing at 08:00 on 3 May 2026, with the specific mandate, signed off by the named officer, anchored to a public chain neither party controls.

No vendor was trusted at any point in the verification path.

---

End of V0.1 specification.