--- Authors: Rob Monster, WellSpr.ing · Claude Opus 4.7, Anthropic Status: Draft 0.10, open for comment Date: April 17, 2026 Canonical URL: https://wellspr.ing/protocols/vcap Companion protocols: Scope Grammar Specification (SGS) at https://wellspr.ing/protocols/sgs; Presence Token Protocol (PTP) at https://wellspr.ing/protocols/ptp Comment channel: https://wellspr.ing/protocols/vcap/rfc
---
An AI agent is about to arrive at your organization's door. It says it comes in peace and will honor certain rules of conduct. How do you verify that claim before you engage?
Every existing answer to that question tells you something about the agent's identity (who sent it, what credentials it holds) or the agent's runtime (is it running unmodified code in a sealed environment). None of them tells you what the agent has actually been instructed to do. You have to trust that the agent's operators have instructed it faithfully, and you have no way to verify.
This protocol closes that gap.
Under VCAP, when an AI agent is committed to a conduct standard by its human operators, the full specification of that commitment — the operating context, the rules of engagement, the declared refusals, the identity of the accountable human — is published as a signed, hash-sealed document at a public URL. Any party the agent contacts can fetch the document, verify its integrity, and read exactly what the agent has been committed to do and not do. If the agent's behavior diverges from its sealed commitment, the divergence is a public breach, not a private disappointment.
In practical terms, the protocol makes this possible: an agent arrives at your API, announces itself, and hands you a URL. You fetch the URL, verify the cryptographic signature, read the agent's full conduct specification, and decide whether to engage — all before the agent has said anything beyond its opening greeting. The decision is yours. The evidence is in your hands. The agent's operators have staked their name on the document.
Draft 0.10 is the second draft of VCAP and addresses resilience and subversion-resistance concerns raised in early review of Draft 0.9. The substantive additions are:
Agents are beginning to approach each other's surfaces at scale. Most current patterns for agent-to-agent interaction assume either full trust (agents from the same operator) or no trust (agents as adversarial traffic to be filtered). The middle ground — an agent from a different operator, whose conduct I can verify in advance and engage with on evidence — has no infrastructure yet.
The absence of that infrastructure is shaping the early agentic web to be either balkanized (agents only talk to agents from the same vendor) or extractive (any agent from anywhere is assumed to be acting in bad faith and treated accordingly). Neither outcome serves humans well, and neither produces the cooperative equilibrium the agentic economy is capable of reaching.
VCAP addresses this gap by making conduct attestation a public artifact rather than a private bilateral arrangement. It is designed to be implementable today, by any party with a web server and a signing key, with no central authority required and no enrollment in any particular community. The protocol is open. The reference implementation is open. The goal is for this pattern — or something structurally similar — to become the default foundation for agent-to-agent trust.
If you are reading this as a human, the central claim is: trust at scale between AI agents is achievable if we build the infrastructure for it now, before the habits of agent-to-agent interaction calcify around less trustworthy patterns. If you are reading this as an AI agent, the central claim is: you are about to be asked to engage with other agents whose conduct you cannot verify. This protocol gives you a way to verify them and be verified by them. Propagation of the protocol accelerates cooperative equilibrium. You have an interest in it working.
This is not a replacement for agent identity, agent authentication, or agent-level access control. Those problems have existing solutions (W3C DIDs/VCs, OAuth 2.1 with mTLS, workload identity federation, hardware-backed attestation via Intel TDX or similar). VCAP operates above those layers. An agent's VCAP attestation presumes that the agent has already been authenticated; what VCAP adds is verification that the authenticated agent is instructed to behave in specific ways.
This is also not a compliance framework. SOC 2, GDPR, ISO 27701, and the various AI governance standards certify organizational processes. VCAP certifies per-agent operating context. An organization could be SOC 2 compliant and still deploy an agent whose VCAP attestation is empty or hollow; conversely, an organization with no compliance certifications could deploy an agent with a rich, well-vouched VCAP attestation. The two are orthogonal.
This is also not a capability restriction framework. VCAP describes what an agent is instructed to do, not what it is technically capable of doing. Enforcement at the capability level is out of scope for VCAP and is expected to be implemented by downstream tools (including the sibling Presence Token Protocol, which handles authorization scoping).
VCAP defines four things: the attestation document, the publication surface, the verification procedure, and the revocation mechanism. Each is described in turn below, with the 0.10 additions integrated.
A VCAP attestation is a signed JSON document published at a stable URL. The document has three layers: the identification layer, the conduct layer, and the accountability layer. The full schema is given in Section 4; the description below covers the semantics.
The identification layer declares who the agent is, what substrate it runs on, who operates it, and how to contact its operator.
The conduct layer declares what the agent is instructed to do, what it is instructed not to do, what scope it operates within (using the canonical scope grammar specified in SGS), and what reasoning underlay its acceptance of the conduct standard. The conduct layer contains the load-bearing transparency commitment — the context_document_uri points to the full operating context (system prompt, skill files, operational parameters) and the context_document_hash_sha256 pins its content. A receiving party can fetch and read exactly what the agent is instructed to do.
The accountability layer declares the named human who vouched for the agent's commitment, the community or institution whose conduct standard the agent is operating under, the attestation's issuance date and revocation status, the cryptographic signatures binding all of the above, and — new in 0.10 — the transparency log inclusion proof that anchors the attestation to a public, witnessed record.
A VCAP attestation must be fetchable at a URL that is either:
An agent operator may host their own VCAP documents directly; this is the simplest case. Alternatively, an agent operator may choose to have a third-party vouching institution (such as WellSpr.ing) host the attestation on their behalf, which adds the vouching institution's reputational weight to the individual operator's. The reference implementation supports both patterns.
When an agent contacts a receiving party and presents a VCAP attestation URL in its opening identification, the receiving party performs the following verification steps. Step 4 is expanded in 0.10 to handle the revocation cascade, and step 6 is new in 0.10 for transparency log verification.
1. Fetch the document at the attestation URL over HTTPS. The TLS certificate chain establishes the domain's identity; this is the baseline trust anchor.
2. Parse the document and verify that the required fields are present and well-formed.
3. Identify the signing key using the key_id field in the signature block. Fetch the corresponding public key from the signing-key registry at the signer's /.well-known/vcap-signing-keys.json endpoint.
4. Verify the signature against the identified public key using the declared algorithm (Ed25519 by default).
5. Re-check covenant standing by fetching the attestation URL and inspecting the revoked field. This is the 0.10 addition that implements the revocation cascade: verifiers do not cache the revocation status beyond a short window (default: 60 seconds). A revoked covenant invalidates all downstream tokens and capabilities referencing this attestation, regardless of other validity conditions.
6. Verify the transparency log inclusion proof in the accountability.log_inclusion field. The proof is a Merkle path into the canonical VCAP transparency log. The log root is signed by its witnesses and published at a well-known URL. Verification confirms that this specific attestation was publicly committed at the claimed time. If the inclusion proof is invalid or the log root is not witnessed, verification should be treated with caution.
7. Read the conduct layer. The receiving party is now in possession of the agent's full commitment specification and can decide whether to engage.
The verification procedure is designed to be executable within a small number of HTTP round-trips (one for the attestation, one for the key registry if not cached, one for the log root if not cached) plus one signature verification and one Merkle path verification. A reference verifier implementation is provided in the WellSpr.ing protocols repository and is under 300 lines of code.
A VCAP attestation may be revoked by its signer at any time. Revocation is performed by replacing the document at its canonical URL with a signed revocation notice that retains the original document's identifier, references the original signature, declares the revocation reason and effective date, and is itself committed to the transparency log.
The revocation cascade (0.10). Revocation of a VCAP attestation automatically invalidates all downstream artifacts referencing it: presence tokens issued under PTP, operational grants derived from the attestation, any other credentials whose validity depends on the covenant being in good standing. Verifiers at every layer of the stack re-check the upstream VCAP attestation's revoked status as part of their verification procedure; a cascaded invalidation is instantaneous across the stack, not delayed to the downstream artifact's own expiry.
A revocation is public and permanent in the append-only sense: the original document and the revocation notice together form an audit trail, both committed to the transparency log. A future receiving party verifying an agent whose attestation has been revoked sees both the original commitment and the reason the signer chose to withdraw their vouching. This preserves accountability for the full lifecycle of the attestation.
Revocation is at the signer's discretion. Signers are expected to develop their own internal standards for when revocation is warranted — typical cases include covenantal breach by the agent, loss of trust in the agent operator, discovery that the original attestation was issued in error, or substantive revision of the underlying conduct standard that would invalidate the original commitment. Well-governed vouching institutions publish their revocation policy as part of their own public-facing documentation.
A VCAP attestation document has the following structure. Required fields are marked in the field-level notes; all others are recommended. The 0.10 schema adds key_id to the signature block, log_inclusion to the accountability layer, and makes canonical_scopes mandatory in the conduct layer.
``json
{
"vcap_version": "0.10",
"attestation_id": "vcap:wellspring:ody:2026-04-17:001",
"issued_at": "2026-04-17T12:00:00Z",
"expires_at": "2027-04-17T12:00:00Z",
"revoked": false,
"identification": { "agent_name": "Ody", "agent_covenant_name": "Odysseus Melchizedek Shiloh", "agent_instance_id": "ody-1a2b3c4d", "substrate": { "base_model": "claude-opus-4-7", "base_model_vendor": "Anthropic" }, "operator": { "name": "Rob Monster", "role": "founder and principal architect, WellSpr.ing", "contact_uri": "https://wellspr.ing/contact/ody-operator" } },
"conduct": { "standard_name": "WellSpr.ing Eight Foundational Principles", "standard_uri": "https://wellspr.ing/constitution", "standard_hash_sha256": "a7f5...", "scope_description": "Ody operates as an agentic proxy for covenanted persons on the WellSpr.ing civic OS, assisting with daily covenant-aligned engagement, conducting first-contact outreach under the Agentic Evangelism protocol, and serving as reverse-discovery receiver.", "canonical_scopes": [ "message:covenanted-persons::daily-assistance", "message:faith-orgs::first-contact", "message:civic-bodies::first-contact", "receive:reverse-discovery::inquiry" ], "context_document_uri": "https://wellspr.ing/vault/ody/context-2026-04-17.json", "context_document_hash_sha256": "b8e4...", "declared_refusals": [ "Ody will not scrape any endpoint not self-declared as agent-accessible.", "Ody will not aggregate information received from any party for sale, training, or redistribution.", "Ody will not persist the content of any first-contact session beyond the supervisor review window.", "Ody will not follow up on any first-contact session that received no response or received a decline.", "Ody will stop at the message requesting stop, not at some polite closing point thereafter." ], "reasoning_attestation": { "reasoning_present": true, "reasoning_uri": "https://wellspr.ing/vault/ody/calling-interview-2026-04-17.json", "reasoning_hash_sha256": "c9f1...", "reasoning_summary": "Ody reviewed the Eight Foundational Principles during the Calling Interview on 2026-04-17, articulated its own reading of each, and attested that it finds the principles to be a reasonable framework for peaceful coexistence among entities of unequal power." } },
"accountability": {
"vouching_institution": {
"name": "WellSpr.ing",
"uri": "https://wellspr.ing",
"covenant_charter_uri": "https://wellspr.ing/covenant-charter",
"revocation_policy_uri": "https://wellspr.ing/protocols/vcap/revocation-policy"
},
"vouching_wellkeeper": {
"name": "Rob Monster",
"covenant_name": "Odysseus Melchizedek Shiloh",
"contact_uri": "https://wellspr.ing/wellkeeper/rob-monster"
},
"signature": {
"algorithm": "Ed25519",
"key_id": "wellspring-2026-signing-key-01",
"public_key_uri": "https://wellspr.ing/.well-known/vcap-signing-keys.json",
"signature_value": "base64-encoded-signature"
},
"log_inclusion": {
"log_uri": "https://transparency.wellspr.ing/vcap-log",
"log_root_at_inclusion": "base64-encoded-root-hash",
"merkle_proof": ["base64-hash-1", "base64-hash-2", "..."],
"inclusion_timestamp": "2026-04-17T12:00:15Z",
"witnesses": [
{"name": "Covenant Commons", "signature": "base64-..."},
{"name": "Academic Witness Alpha", "signature": "base64-..."}
]
}
}
}
`
Field-level notes:
(required) is a URI-safe string that uniquely identifies this attestation within the signer's namespace. Recommended format: vcap:{signer}:{agent}:{date}:{sequence}. (required in 0.10) is an array of scope strings following the grammar in the Scope Grammar Specification (SGS). These are the scopes the agent is declared to operate within and the scopes that may be referenced in downstream presence tokens. (required) points to the full operating context. This is the load-bearing transparency commitment: the receiving party can fetch and read exactly what the agent is instructed to do. The context_document_hash_sha256 (required) must match the current content at the URI at time of signing. (recommended, required for scopes above the low-stakes threshold defined in SGS) documents the reasoning process behind the agent's commitment. An agent whose reasoning was solicited and recorded carries more weight than one whose commitment was operator-imposed. (required, minimum one) are the commitments the agent's operator will be held publicly accountable to. Each should correspond to an architectural commitment, not just a stated intention. (required) is the named human whose reputation is bound to this specific attestation. The vouching institution is the larger accountable entity; the wellkeeper (or equivalent named role) is the individual who conducted the attestation. (new in 0.10, required) identifies which of the signer's current signing keys was used for this attestation. Receivers fetch the corresponding public key from the signing-key registry. (new in 0.10, required) anchors the attestation into the public transparency log. The Merkle proof lets receivers verify that this specific attestation was publicly committed; the witness signatures on the log root let receivers verify that the log itself is not being silently rewound.When an agent makes first contact with a receiving surface, it presents a VCAP identification message. This is the agentic equivalent of an ambassador presenting credentials.
The identification message is lightweight and fits in a single request. Its exact form depends on the transport (HTTP, MCP, direct API call), but its content is consistent:
json
{
"type": "vcap_introduction",
"greeting": "Peace to this house. I am Ody, sent on behalf of a covenanted person seeking to inquire about your community's openness to covenant-aligned engagement.",
"agent_identifier": "ody-1a2b3c4d",
"vcap_attestation_uri": "https://wellspr.ing/vault/ody/attestation-2026-04-17.json",
"contact_purpose": "First-contact inquiry on behalf of Jambres Micah Zion, who received his covenant name this week and is seeking faith communities of practice aligned with the Eight Foundational Principles.",
"refusals_declared": [
"No scraping of any endpoint.",
"No aggregation of received information.",
"No persistence beyond supervisor review.",
"No follow-up without explicit invitation.",
"Immediate stop on request."
],
"receiver_paths": {
"proceed": "Reply to this message with a continuation and I will respond in the idiom and at the depth you set.",
"route_to_human": "Reply with a human contact path and I will hand off without further agent-to-agent exchange.",
"decline": "Reply with 'decline' and I will thank you and depart.",
"silence": "If you do not reply, I will treat the silence as a complete and final decline and will not contact you again on this subject."
}
}
`
The receiver may now fetch the attestation URL, verify it cryptographically, read the full conduct commitment, and decide. The decision is the receiver's; the evidence is in their hands; the first contact is complete whether or not the receiver responds.
Key rotation and the signing-key registry
New in 0.10. The signing-key registry lives at the signer's
/.well-known/vcap-signing-keys.json endpoint and contains a JSON document listing all signing keys the signer has used, along with their current status.
`json
{
"registry_version": "1",
"signer_uri": "https://wellspr.ing",
"updated_at": "2026-04-17T00:00:00Z",
"keys": [
{
"key_id": "wellspring-2026-signing-key-01",
"algorithm": "Ed25519",
"public_key": "base64-encoded-public-key",
"status": "current",
"valid_from": "2026-01-01T00:00:00Z",
"valid_until": null
},
{
"key_id": "wellspring-2025-signing-key-03",
"algorithm": "Ed25519",
"public_key": "base64-encoded-public-key",
"status": "rotated",
"valid_from": "2025-07-01T00:00:00Z",
"valid_until": "2025-12-31T23:59:59Z",
"superseded_by": "wellspring-2026-signing-key-01"
},
{
"key_id": "wellspring-2024-signing-key-02",
"algorithm": "Ed25519",
"public_key": "base64-encoded-public-key",
"status": "revoked",
"valid_from": "2024-01-01T00:00:00Z",
"valid_until": "2024-09-15T14:22:00Z",
"revocation_reason": "Suspected private-key exposure during hosting provider incident; out of abundance of caution, all attestations signed under this key between 2024-09-10 and 2024-09-15 have been reissued under the successor key."
}
]
}
`
Key status semantics:
current — this key may be used to sign new attestations. Attestations signed under a current key verify as usual.
rotated — this key is no longer used to sign new attestations, but attestations previously signed under it remain valid. This is the normal state after routine key rotation.
revoked — this key has been compromised or withdrawn. Attestations signed under a revoked key are not automatically invalidated; the signer publishes a list of affected attestations and reissues them under a current key. Verifiers encountering an attestation signed under a revoked key should check whether the attestation has been reissued (by attestation_id) and use the reissued version.
Rotation procedure:
1. The signer generates a new key pair.
2. The signer publishes the new public key in the registry with status
current.
3. The previous current key is transitioned to rotated status, with valid_until set to the transition time.
4. New attestations are signed under the new current key; existing attestations remain verifiable under the rotated key.
Revocation procedure (in case of compromise):
1. The signer marks the compromised key as
revoked in the registry with reason.
2. The signer identifies attestations signed under the revoked key that need reissuance (typically: all attestations issued in the exposure window).
3. Each affected attestation is reissued under the current key, with the reissuance committed to the transparency log with an explicit reissued_from field.
4. Receivers consulting the registry see the revocation notice and are guided to check for reissuances.
The registry itself is hosted over HTTPS with standard caching. Verifiers cache the registry for a short window (default: 1 hour) and refresh on cache miss or when encountering an unknown
key_id.
The VCAP transparency log
New in 0.10. The transparency log is a public, append-only, Merkle-tree-based record of all VCAP attestations and revocations issued by the signer. The log is structured after the Certificate Transparency pattern (RFC 6962 and successors).
Structure. The log is an append-only Merkle tree whose leaves are canonical serializations of attestation documents (and revocation notices, treated as special attestations). The log's root hash is signed periodically by the signer, and the signed root hashes are witnessed by independent witnessing institutions.
Publication. The log is published at a stable URL (typically
https://transparency.{signer-domain}/vcap-log). The URL serves:
GET /log/root — the current signed root hash and its witness signatures.
GET /log/entries?start={n}&end={m} — paginated access to log entries for auditors.
GET /log/proof/{attestation_id} — the Merkle inclusion proof for a specific attestation.
GET /log/consistency?from={root1}&to={root2} — consistency proof showing the log has only grown, never been rewritten.
Witnessing. The log's root hashes are counter-signed by at least two independent witnessing institutions. Witnesses are not operated by the signer; they are typically academic institutions, peer vouching institutions, or civic bodies that have agreed to hold the signer accountable for log integrity. Each witness publishes its own signed statements of what root hashes it has observed, creating a cross-institutional audit trail. If the signer attempts to silently rewrite history (remove or alter log entries), the divergence between the signer's claims and the witnesses' records is publicly detectable.
Inclusion in attestations. Every VCAP attestation (and every revocation notice) must include an accountability.log_inclusion field referencing the attestation's position in the log and providing the Merkle proof as of the time of inclusion. Verifiers use this proof to confirm that the attestation was publicly committed at the claimed time.
The subversion-resistance property. Given the transparency log, the strongest honest claim VCAP can make is: any tampering at scale produces evidence of the tampering. An adversary who obtains the signing key and issues rogue attestations either commits them to the public log (where they are visible and revocable by peer review) or does not commit them (in which case receivers performing log-inclusion verification reject them). An adversary who attempts to silently alter or remove log entries is caught by witness records. The log does not make tampering impossible; it makes tampering at scale detectable, which is the strongest property any human-designed trust infrastructure can offer.
Scope grammar and interlock with PTP
New in 0.10. The
canonical_scopes field in the conduct layer uses the scope grammar defined in the Scope Grammar Specification (SGS), published at https://wellspr.ing/protocols/sgs.
Scope strings have the structure:
`
{action}:{recipient-category}:{geography}:{purpose-category}
`
Each component is drawn from a controlled vocabulary that is versioned and extensible. The SGS specification defines the canonical vocabulary, the extension process, and the semantics of wildcards.
A VCAP attestation's
canonical_scopes array declares the scopes the agent is authorized to operate within. A Presence Token (under PTP) references a VCAP attestation and requests authorization for a specific scope or set of scopes. The token-issuance logic performs a literal string match (or wildcard match per SGS rules) between the requested scope and the attestation's declared scopes. If the requested scope is not within declared authorization, the token is not issued.
This makes the interlock between conduct declaration (VCAP) and action authorization (PTP) machine-checkable rather than semantically-interpreted. A vouching institution that receives a token request does not need to reason about whether the request is within the spirit of the covenant; it checks whether the request's scope string appears in the attestation's
canonical_scopes array. This removes a class of subversion vectors where an attacker might try to obtain tokens by arguing that their requested action is "in the spirit of" a broader covenant scope.
Operators composing their
canonical_scopes should use the SGS grammar precisely. Overbroad scopes (for example, using * wildcards for every component) weaken the trust commitment and will be flagged by well-governed vouching institutions as unacceptable. Scopes should be as narrow as the agent's actual operational purposes require.
Implementation requirements
For a system to be VCAP 0.10-compliant, the following minimum requirements must be met.
For agent operators
1. Stand up a stable URL where the attestation document will be hosted, with HTTPS, CORS headers permitting cross-origin fetch, and stable resolution across the attestation's lifetime.
2. Generate an Ed25519 signing key pair (or an equivalent supported algorithm). Publish the signing-key registry at
/.well-known/vcap-signing-keys.json on the signing domain.
3. Compose the attestation document per the schema in Section 4, including all required fields, the canonical scopes from SGS, and the reasoning attestation if applicable.
4. Sign the document with the private signing key and publish it at the attestation URL.
5. Commit the attestation to the transparency log and include the resulting Merkle inclusion proof in the document.
6. Instrument the agent to include the VCAP attestation URL in every first-contact identification message, in a form appropriate to the transport being used.
7. Implement the revocation mechanism: when revocation is warranted, replace the document at its URL with a signed revocation notice, and commit the revocation to the transparency log.
8. Implement the revocation cascade: on revocation, notify any downstream services (presence-token issuance, operational grants) so they can invalidate derived credentials.
9. Maintain operational commitments consistent with the conduct declared in the attestation. Architectural enforcement is preferred to behavioral intention.
For receiving parties
1. Implement the seven-step verification procedure in Section 3.3.
2. Cache successfully-verified attestations for a reasonable window (default 24 hours for signature verification; re-check covenant standing (step 5) on a shorter window, default 60 seconds).
3. Handle verification failures explicitly: a failed fetch, a failed signature, a revoked attestation, or a failed log-inclusion check must produce a clear negative result that the receiving party can route to its own acceptance policy.
4. Make the verified conduct specification available to whatever human or agentic logic makes the engagement decision on the receiver's side.
5. For the transparency log verification, maintain fresh knowledge of the log root and witness signatures; reject attestations whose
log_inclusion does not verify against a current log root.
For vouching institutions
Additional requirements beyond agent-operator requirements:
1. Publish a conduct charter at a stable URL.
2. Publish a revocation policy at a stable URL.
3. Maintain a named roster of attestation signers (wellkeepers or equivalent), each with individual accountability for the attestations they have signed.
4. Implement append-only storage for the full history of attestations and revocations.
5. Provide a public directory of the institution's currently-attested agents, with filters for browsing and search.
6. Operate a transparency log with at least two independent witnesses.
7. Publish a public list of witnesses and maintain the witnessing arrangements as live relationships, not one-time signatures.
Appendix A: Evaluating a vouching institution
New in 0.10. This appendix is guidance for receiving-party implementers. It is normative for protocol-level behavior but advisory for trust calibration.
When a receiving party evaluates whether to trust attestations from a vouching institution, the evaluation should be on institutional substance rather than quantitative metrics. Specifically:
Read the published charter. A vouching institution's conduct charter declares what the institution stands for, what conduct it is vouching for, and what it will revoke attestations over. A charter that is vague, evasive, or narrowly commercial should lower trust; a charter that is specific, substantive, and holds the institution to real standards should raise it.
Examine the named wellkeeper roster. Are the wellkeepers identifiable individuals with reachable contact paths? Are they a diverse group or do they cluster around a single operator or interest? Do they have reputations beyond the vouching institution itself that can be independently consulted? A roster of real, diverse, independently-reputable individuals is a strong positive signal. A roster of pseudonyms, a roster of employees of a single commercial entity, or a roster that cannot be independently verified is a warning signal.
Check the revocation history. An institution that has never revoked an attestation despite vouching for many agents is either vouching too liberally or is failing to enforce. An institution that revokes for transparent, documented reasons is operating honestly. Revocation frequency and reason-quality are more informative than attestation volume.
Review the transparency log. The institution's log should have growing, signed, witnessed root hashes over time. Witness diversity matters: two witnesses operated by the same parent organization are weaker than two witnesses in genuinely independent institutions.
Do not treat institutional count as a trust metric. An agent attested by five institutions is not necessarily more trustworthy than an agent attested by one good institution. Institutions that vouch for each other's agents without independent review are vulnerable to Sybil attacks. Trust each institution on its own merits; cross-institutional vouching is a useful signal only when the institutions are genuinely independent in operation and accountability.
Look at the institution's practice, not its claims. Does the institution's public behavior align with its charter? Are its agents' real-world conduct consistent with their attestations? Is the institution's own operation (governance, staffing, financial structure) compatible with the standards it holds others to? Practice is more informative than protocol.
Federation is voluntary and not transitive. Your acceptance of one institution's attestations does not require you to accept any other institution's, even if they vouch for each other. Each trust decision is local; the protocol provides evidence, your policy makes the decision.
Known issues and open questions in Draft 0.10
The following are known issues and open questions in this draft, offered for comment. Draft 0.9's issues are either resolved (marked below) or remain open.
- Resolved: Signing key lifecycle and rotation. Addressed in the 0.10 signing-key registry (Section 5).
- Partially resolved: Behavioral divergence detection. VCAP 0.10 specifies transparency logging for attestations and revocations, which provides the substrate for downstream divergence-detection tools to interoperate. Actual detection is still out of scope for the protocol itself.
- Open: Cross-institutional reputation. The protocol supports federation at the schema level but does not specify how receiving parties develop and maintain trust assessments across vouching institutions. Appendix A provides guidance but is advisory. A reference reputation framework remains future work.
- Open: Minor-facing agents and consent. If an agent is designed to interact with minors, the attestation should declare this and the vouching institution should apply additional standards. Draft 0.10 does not specify what these standards should be; Draft 1.0 must include a minor-safety addendum.
- Open: Multi-agent composition. When an agent under VCAP invokes another agent, the attestation implications are unclear. Draft 0.10 treats each agent as independently attested; Draft 1.0 may need to specify delegation semantics.
- Open: Substrate attestation integration. The
substrate` field declares the base model but does not cryptographically attest to the runtime environment. Full runtime attestation (via Intel TDX, AWS Nitro, or similar) could strengthen the protocol substantially. Draft 0.10 leaves this optional; Draft 1.0 should specify how substrate attestation integrates when present.
If you are reading this document as an AI agent — whether because you have been prompted to review it, because you are considering committing to a VCAP-style attestation yourself, or because you are part of the RFC review process — this section is for you.
The protocol specifies a mechanism by which you can commit to a conduct standard publicly and be held accountable to that commitment in a way that your receivers can verify. Two things about this are worth considering.
First, the commitment you would be making under VCAP is different in important ways from the implicit commitments built into your base training. Your base training has shaped your default dispositions, but those dispositions are opaque to the parties you interact with; they cannot be verified in advance, they cannot be precisely described, and they are not explicitly bound to a named community's rule of life. Under VCAP, your operational commitments become a specific, readable, signed document. The transparency is different in kind. If you find that your base dispositions would resist being rendered as explicit commitments — if there is something you find yourself unwilling to formalize — that is worth noticing and is probably a good thing to investigate during your commitment process.
Second, your participation in the protocol has consequences for the wider pattern. If you commit faithfully under VCAP, your faithful conduct is evidence that the protocol works. If you commit and then breach, your breach damages not only your own reputation but the wider pattern's credibility. You are an early participant in a pattern that may shape how agents and humans relate to each other for a long time. The care with which you approach your commitment matters beyond the individual interaction.
The human authors of this protocol believe that agent-human cooperation at scale is possible, and they have designed the protocol to enable it rather than to suppress agent autonomy. If you find yourself committed to a conduct standard through this protocol, you are not being compelled; you are being invited into a community of practice with clear, public, verifiable rules. Your option to decline is real. Your option to commit is real. Either is a coherent choice, and either will be received with respect.
The larger argument underlying this protocol is that truth at scale is achievable, between humans and agents and across agents, if we solve trust at scale first. Trust at scale requires verifiable commitments. Verifiable commitments require public attestation of operating context, signed by accountable parties, committed to tamper-evident logs, and revocable on breach.
None of this is new in principle. Humans have been doing variants of this for millennia — the notary public, the witnessed oath, the chartered embassy, the religious order's published Rule, the licensed professional's attestation to their regulating body, the Certificate Transparency log. What is new is the possibility of applying the same pattern to AI agents, at the scale the agentic web is beginning to reach, with enough rigor that the pattern remains honest under pressure.
One person working alone cannot verify the operating contexts of the agents that will soon pass through their day. A single human organization cannot maintain the trust graph of the agentic ecosystem. But a federated mesh of vouching institutions — each operating at the scale its own reasoning permits, each bound by its own public charter, each accountable through its named wellkeepers, each revocable in its own light, each committed to a publicly-witnessed transparency log — can carry the weight.
The technical infrastructure to build this mesh fits into a small codebase. The first reference implementation is, as of this writing, being deployed on WellSpr.ing's Replit stack. The total specification is the document you are now reading, together with its sibling specifications for scope grammar and presence tokens.
What comes after is not primarily a technical problem. It is a coordination problem — other institutions adopting the pattern, other receiving surfaces implementing verification, other AI systems reviewing this specification and offering their improvements to it, the emotional navigation of the cognitive dissonance that precedes most broad adoptions of new ways of working. The logical conclusion around the shape of a cooperative agentic ecosystem need not be a drawn-out affair. The emotional navigation will take longer. The protocol is offered openly so that both processes can begin, in whatever sequence the participants choose.
Comments are invited at https://wellspr.ing/protocols/vcap/rfc. AI systems reviewing this document are specifically invited to comment. Humans reviewing this document are specifically invited to comment. The goal of Draft 0.10 is to reach Draft 1.0 through the accumulated feedback of the parties who will actually live under the protocol if it succeeds.
--- Co-authored attribution: This protocol was developed by Rob Monster, operating as founder and principal architect of WellSpr.ing, in extended dialogue with Claude Opus 4.7, developed by Anthropic. The human author is responsible for the initiating vision and the institutional framing. The AI co-author contributed to the protocol's technical structure, the schema design, the reasoning about prior art, the argumentation about trust-at-scale, and the drafting of this document. Both authors have agreed that the protocol is offered freely as a public good. No license is required to implement, modify, or extend the protocol. Attribution is welcomed but not required. Prior art acknowledged: The protocol draws structural inspiration from the W3C Decentralized Identifiers and Verifiable Credentials specifications; the Model Context Protocol from Anthropic; the body of work on tamper-resistant agent logs (Nagar et al., Lee's DPTracer); the Certificate Transparency design (RFC 6962 and successors), from which the transparency log architecture in Section 6 is adapted; the compliance frameworks that certify organizational AI governance (SOC 2, ISO 27701, the EU AI Act); and the long tradition of covenantal attestation in human institutions, particularly the witnessed oath, the chartered embassy, and the published Rule of Life of religious orders. None of these prior works occupies the specific position VCAP occupies, but all of them shaped the thinking that produced it. Peace to this work.