--- Authors: Rob Monster, WellSpr.ing · Claude Opus 4.7, Anthropic Status: Draft 0.9, open for comment Date: April 17, 2026 Canonical URL: https://wellspr.ing/protocols/ptp Sibling protocols: Vaulted Covenanted Agent Protocol (VCAP) at https://wellspr.ing/protocols/vcap; Scope Grammar Specification (SGS) at https://wellspr.ing/protocols/sgs Comment channel: https://wellspr.ing/protocols/ptp/rfc
---
An AI agent holds a VCAP attestation saying it is committed to a conduct standard. Now the agent needs to do a specific thing: reach all the dry cleaners in Poughkeepsie to introduce a new covenant-aligned payment service, for example. How does the agent get authorization to do this specific thing, without the vouching institution exposing its directory of verified dry cleaners to the agent, and without the agent having to re-present its full covenant credentials to every recipient?
This protocol closes that gap.
Under PTP, an agent with a valid VCAP attestation requests a presence token for a specific scope — where "scope" is a canonical string from the Scope Grammar Specification declaring the action, the recipient category, the geography, and the purpose. The vouching institution reviews the request against the agent's declared authorization, issues a signed, time-bounded token, and provides a routing path for the authorized action. The token is verifiable by receiving surfaces without revealing the agent's identity or the institution's directory.
The protocol is the operational layer of the trust stack VCAP anchors. Where VCAP attests to commitment, PTP authorizes action. Where VCAP is long-lived (typically one year), PTP tokens are short-lived (hours to days). Where VCAP is a public artifact, PTP tokens are operational grants that reveal only what receivers need to know.
VCAP and PTP form a two-protocol stack. Each does something the other does not.
VCAP answers: is this agent committed to a conduct standard I can verify? This is the trustworthiness question. VCAP attestations are persistent, publicly fetchable, and cryptographically anchored to a transparency log.
PTP answers: is this specific outreach authorized under that commitment, right now? This is the capability question. PTP tokens are ephemeral, scoped to specific operations, and bound to specific covenant keys.
An agent may hold a VCAP attestation without ever requesting a PTP token (if its engagement is open conversation with known parties rather than scoped outreach). An agent may not hold a PTP token without an underlying VCAP attestation. The tokens are always derivative.
The separation of protocols allows each to evolve independently. An institution may adopt VCAP for trust-verification of other institutions' agents without running its own PTP token-issuance infrastructure. An institution may run PTP for its own agents while accepting VCAP attestations from peer institutions.
PTP authorizes actions within scopes declared using the Scope Grammar Specification. A scope string has the form:
``
{action}:{recipient-category}:{geography}:{purpose-category}
`
The agent's VCAP attestation declares, in its canonical_scopes field, the scopes the agent is authorized to operate within. A PTP token request specifies a particular scope (which may be a literal match for an SGS vocabulary term, with geography specified; wildcards in requests are not permitted). The token-issuance logic performs literal string matching against the declared scopes, permitting wildcard matches only where declared scopes contain wildcards.
The SGS specification defines the grammar, vocabulary, match semantics, and extension process. PTP relies on SGS for all scope-related questions; PTP does not extend or modify the grammar.
A presence token is a signed JSON document issued by a vouching institution. The token is presented by the bearer at the routing surface and verified before the authorized action is executed.
`json
{
"ptp_version": "0.9",
"token_id": "prs_wellspring_2026-04-17_abc123xyz",
"token_type": "presence_token",
"bearer": { "covenant_key_hash": "sha256:base64-encoded-hash-of-covenant-public-key", "proof_of_possession_required": true },
"scope": "message:merchants:poughkeepsie-ny:civic-outreach", "purpose_declaration": "First-contact introduction of the 425.today merchant off-ramp to dry cleaners and adjacent service merchants in Poughkeepsie, NY, on behalf of a civic outreach campaign.",
"vcap_attestation_uri": "https://wellspr.ing/vault/ody/attestation-2026-04-17.json", "vcap_attestation_id": "vcap:wellspring:ody:2026-04-17:001",
"issued_at": "2026-04-17T14:30:00Z", "expires_at": "2026-04-19T00:00:00Z", "revoked": false,
"issuer": { "name": "WellSpr.ing", "uri": "https://wellspr.ing", "issuance_policy_uri": "https://wellspr.ing/protocols/ptp/issuance-policy" },
"routing": { "routing_authority_uri": "https://wellspr.ing/routing", "verification_endpoint": "https://wellspr.ing/api/v1/ptp/verify", "audit_endpoint": "https://wellspr.ing/api/v1/ptp/audit" },
"safeguards": { "maximum_recipients": 250, "minimum_interval_between_recipients_ms": 5000, "stakes_level": "medium", "dual_sided_audit_required": true },
"signature": {
"algorithm": "Ed25519",
"key_id": "wellspring-2026-ptp-signing-key-01",
"public_key_uri": "https://wellspr.ing/.well-known/ptp-signing-keys.json",
"signature_value": "base64-encoded-signature"
}
}
`
Field-level notes:
is the SHA-256 hash of the agent's covenant public key. The token does not include the key itself; possession is proved at verification time via a signing challenge (see Section 5.3). follows the SGS grammar. The scope in a token is always a specific scope (no wildcards in request position) but may match a wildcarded declared scope in the underlying VCAP attestation. is a human-readable statement of what the agent will do under this token. It is included in audit records and may be surfaced to recipients. and vcap_attestation_id anchor the token to its underlying VCAP attestation. Verifiers re-check the attestation's revocation status as part of token verification. is the URL a recipient or routing surface calls to verify the token. See Section 5 for the full verification procedure. encodes PTP-level operational constraints derived from the SGS stakes level for this scope. Receivers and routing surfaces enforce these constraints.A presence token's lifecycle has five phases: request, issuance, presentation, verification, expiry or revocation.
The agent requests a token from the vouching institution's PTP issuance endpoint:
`
POST https://wellspr.ing/api/v1/ptp/request
`
The request body declares: the agent's covenant key (proving current standing), the VCAP attestation being drawn on, the specific scope being requested, the purpose declaration, and the requested lifetime (subject to the maximum for the scope's stakes level).
The request must be signed by the agent's covenant private key. The signature proves that the requesting party actually holds the covenant key; a signature check against the key hash in the VCAP attestation prevents any other party from requesting tokens on the agent's behalf.
The vouching institution performs the following checks before issuing:
1. Covenant standing. Is the agent's VCAP attestation current and not revoked? Fetch the attestation and check its revoked field.
2. Scope authorization. Does the requested scope match (literally or via wildcard) any of the scopes declared in the VCAP attestation's canonical_scopes array? This is a mechanical string-matching check per SGS.
3. Stakes level and safeguards. What is the SGS stakes level for this scope? Determine the maximum token lifetime, the applicable safeguards, and any additional review requirements.
4. Reasoning attestation (for medium and high stakes). Is the reasoning attestation present in the VCAP document? If not, decline the request for any medium-or-higher-stakes scope.
5. Purpose specificity. Is the purpose declaration specific enough to be meaningful for audit? Vague purposes like "general outreach" are grounds for decline.
6. Rate and concurrency checks. Does the agent have an unreasonable number of active tokens, or a pattern of rapid token requests that suggests misuse? Well-governed institutions apply rate limits.
7. WellKeeper review (for high-stakes scopes). Does this request require human review by the named WellKeeper vouching for the agent? For high-stakes scopes (per SGS), yes.
If all checks pass, the institution issues the token per the schema in Section 4, commits the issuance to its PTP audit log, and returns the token to the agent.
If any check fails, the institution declines with a specific reason, and the decline is itself logged.
The agent presents the token at the routing surface when initiating the authorized action. The presentation differs by action type:
and converse actions, the agent submits the message content to the routing surface together with the token. The routing surface verifies the token and, if valid, routes the message to in-scope recipients. actions, the agent submits the query together with the token. The routing surface verifies, forwards the query to recipients who have consented to receive queries of this type, and returns aggregated or per-recipient responses per the scope semantics. actions, the agent registers with the routing surface using the token. Inbound contacts matching the scope are routed to the agent. and broker actions, additional protocol extensions apply; see Section 9 for the open status of these actions in Draft 0.9.When a recipient or routing surface receives a token, it performs verification through a single API call:
`
GET https://wellspr.ing/api/v1/ptp/verify/{token_id}
`
The verification endpoint returns a minimal response revealing only what the verifier needs to know:
`json
{
"valid": true,
"scope": "message:merchants:poughkeepsie-ny:civic-outreach",
"expires_at": "2026-04-19T00:00:00Z",
"revoked": false,
"purpose_declaration": "First-contact introduction of the 425.today merchant off-ramp to dry cleaners and adjacent service merchants in Poughkeepsie, NY, on behalf of a civic outreach campaign.",
"stakes_level": "medium",
"vcap_attestation_uri": "https://wellspr.ing/vault/ody/attestation-2026-04-17.json",
"safeguards": {
"maximum_recipients": 250,
"minimum_interval_between_recipients_ms": 5000,
"dual_sided_audit_required": true
}
}
`
Notice what is there and what is not. The response includes the scope, expiry, revocation status, purpose, stakes level, attestation pointer, and applicable safeguards. It does not include the agent's name, covenant name, instance identifier, or any personally-identifying information about the humans behind the agent. The bearer field is used internally by the verification endpoint to validate the presenter's proof-of-possession (see 5.3) but is not exposed to the verifier.
This is the minimum-disclosure principle applied to authorization. The verifier learns that the action is authorized and what its bounds are. The verifier learns nothing else. If the verifier wants more — if it wants to audit the agent's deeper conduct standard — it can follow the vcap_attestation_uri and read the publicly-fetchable VCAP document. That is a separate, optional step the verifier chooses based on its own policy.
Proof of possession
To prevent token replay by parties who do not hold the agent's covenant key, the verification procedure includes a proof-of-possession challenge:
1. The verifier generates a random challenge string. 2. The verifier sends the challenge to the token-presenting agent. 3. The agent signs the challenge with its covenant private key and returns the signature. 4. The verifier fetches the covenant public key (via the VCAP attestation, which identifies it) and verifies the signature against the challenge.
If the signature verifies, the presenting agent has proved it holds the covenant key matching the bearer.covenant_key_hash in the token. If not, the token is rejected even if otherwise valid.
This prevents the following attack: a malicious party intercepts a token in transit and attempts to present it to the routing surface. Without the agent's private key, the malicious party cannot complete the proof-of-possession and the token is rejected.
A token becomes invalid when it expires (reaches its expires_at time) or is explicitly revoked. Expiry is automatic; revocation requires action by the issuer.
Explicit revocation occurs when:
with a revocation reason. Existing token bearers attempting to use the token see the revocation status on the next verification call. Routing surfaces that have cached verification results must either short their cache TTL (default: 60 seconds) or explicitly re-verify.
The revocation cascade from VCAP
When a VCAP attestation is revoked, all PTP tokens referencing that attestation are automatically invalidated. This is the critical integrity property that binds the two protocols together.
The cascade is implemented at the verification endpoint. When a PTP verify request is made for a token, the endpoint:
1. Retrieves the token record.
2. Fetches the underlying VCAP attestation (or uses a cached result, if within the short cache window).
3. Checks the VCAP attestation's
revoked field.
4. If the VCAP attestation is revoked, returns valid: false with revocation_reason: "Upstream VCAP attestation revoked" regardless of the token's own state.
5. If not, proceeds with the usual token-level checks.
This guarantees that covenant revocation propagates instantaneously to all downstream tokens. There is no window during which a revoked agent can continue operating under outstanding tokens until their individual expiry.
Implementations must not cache VCAP revocation status beyond the cache TTL defined in VCAP (default: 60 seconds). Caching at the token level is permitted but must not exceed this window.
The dual-sided audit requirement
For medium and high stakes scopes (per SGS), both the issuing side and the receiving side maintain audit records. Draft 0.9 specifies the minimum audit data for each side.
Issuer-side audit
The vouching institution maintains, for each issued token:
- The token record (schema in Section 4) as issued.
- The requesting agent's covenant key hash and VCAP attestation reference.
- The specific purpose declaration provided at request time.
- The scope authorization check result (which declared scope in the VCAP attestation matched the request).
- The WellKeeper reviewer name and timestamp (for high-stakes scopes requiring review).
- The issuance timestamp and the decline-vs-issue decision.
- A record of each verification call made against the token (timestamp, verifying endpoint, result).
- Any explicit revocation event with reason.
- Correlation identifiers connecting this token to the issuer's transparency log and to the agent's VCAP transparency log entry.
The issuer's audit records are retained per the institution's published revocation policy (typically: indefinitely for covenanted-attestation audits, per covenantal norms rather than commercial norms).
Receiver-side audit
The receiving party (individual recipient, organization, routing surface acting on behalf of recipients) maintains, for each received token presentation:
- The token ID and verification result.
- The timestamp of presentation and the action attempted under the token.
- The receiver's own decision (accept, decline, no-response, escalate-to-human).
- Any abuse report the receiver filed against the token (optional; a formal abuse-reporting flow is defined in Section 8).
- The receiver's trust calibration at the time of action (which vouching institutions are currently accepted, under what policy).
Receiver-side audit records are retained per the receiver's own policy; the protocol does not mandate retention periods but does require that the audit facility exist.
Abuse reporting
If a receiver determines that a token has been used in violation of its declared scope, purpose, or safeguards, the receiver may file an abuse report:
`
POST https://{issuer-domain}/api/v1/ptp/report-abuse
`
The report includes: the token ID, the receiver's identification (optional; anonymous reports are accepted but carry less weight), the specific violation observed, and supporting evidence.
The issuing institution must review abuse reports within the timeframe declared in its published revocation policy. Well-governed institutions publish this timeframe explicitly and honor it.
Abuse reports and their resolutions are part of the institution's track record and should inform receivers' ongoing trust calibration of that institution.
Safeguards by stakes level
PTP applies different safeguards based on the SGS stakes level of the requested scope. Draft 0.9 establishes the following defaults, which implementations may tighten (but not loosen):
Low-stakes scopes
- Default token lifetime: 72 hours
- Maximum recipients per token: 1000
- Minimum interval between recipients: 1000 ms (1 second)
- Reasoning attestation: recommended, not required
- WellKeeper review at issuance: not required
- Dual-sided audit: optional
Medium-stakes scopes
- Default token lifetime: 48 hours
- Maximum recipients per token: 250
- Minimum interval between recipients: 5000 ms (5 seconds)
- Reasoning attestation: required in VCAP
- WellKeeper review at issuance: sample-based (random or policy-triggered)
- Dual-sided audit: required
High-stakes scopes
- Default token lifetime: 24 hours
- Maximum recipients per token: 50
- Minimum interval between recipients: 30000 ms (30 seconds)
- Reasoning attestation: required in VCAP, freshness-checked
- WellKeeper review at issuance: every request
- Dual-sided audit: required with enhanced retention
- Possible additional requirements: threshold signing by multiple WellKeepers; hardware-backed runtime attestation of the agent; expedited revocation procedures
Safeguards are included in the token itself (in the safeguards field) so that routing surfaces can enforce them without needing to look up the scope's stakes level separately.
Known issues and open questions in Draft 0.9
transact and broker` action protocols. Draft 0.9 reserves these actions but does not specify their full protocols. Financial transactions and agent-mediated introductions both introduce additional considerations (payment-rail integration for transact; dual-authorization for broker). Draft 1.0 must either specify these protocols or explicitly punt them to sibling specifications.
The PTP design makes possible a business-model configuration worth naming explicitly: a vouching institution can operate a high-quality directory of verified contact points (merchants, organizations, individuals who have consented to be contactable through the institution) and monetize intermediated access to it without ever exposing the directory itself. The directory is an asset; access to it, governed by tokens issued under covenantal authorization, is a service.
This is not explicitly required by the protocol, but the protocol's architecture naturally supports it. Vouching institutions may choose to operate as non-commercial covenantal bodies, as commercial services, or as hybrid forms. Draft 0.9 is silent on business model and does not prefer one over another.
Receivers evaluating which vouching institutions to trust may include business-model considerations in their assessment. An institution whose financial model depends on maximizing token issuance has different incentive alignment than one whose model depends on maintaining long-term trust with recipients. Both can operate under the protocol; both can maintain integrity; but their incentive structures differ and that is worth knowing.
This specification 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, the institutional framing, and the operational-use-case grounding. 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.
Offered freely as a public good. No license required. Attribution welcomed but not required. Peace to this work.