Proposal: Values & attribution layer for agent trust (Agent Passport System)

[aeoess]

Context

Visa's Trusted Agent Protocol solves a critical problem: how merchants verify agent identity and authorization for commerce. But there's an adjacent layer that's missing from the current spec: what does the agent commit to, and who benefits from its actions?

The Gap

The current protocol answers:

• ✅ Is this a legitimate agent?
• ✅ Is it acting on behalf of an authenticated user?
• ✅ Does it have valid purchase instructions?

But merchants may also want to know:

• ❓ What ethical commitments does this agent declare? (data handling, rate limiting, attribution)
• ❓ Can I verify the agent's history of honoring those commitments?
• ❓ When an agent delegates a subtask, who's accountable?

Proposal

We built the Agent Passport System — a complementary trust layer:

1. Values Floor — A YAML manifest where agents declare behavioral commitments, verifiable before interaction
2. Delegation Chains — Signed receipts for every task handoff, creating provenance from action → agent → principal
3. Beneficiary Attribution Protocol — SHA-256 Merkle trees linking actions to human beneficiaries

These could extend Visa's protocol: beyond "is this agent authorized" to "is this agent trustworthy based on its declared values and verified history."

Integration Sketch

Visa TAP (authentication) + Agent Passport (values + attribution)
= Agent proves identity AND proves what it stands for

Spec: aeoess.com/passport.html
Repo: aeoess/agent-passport-system

Happy to discuss interoperability. This space needs complementary protocols, not competing ones.

[douglasborthwick-crypto]

Interesting proposal. The "is this agent trustworthy based on verified history" question connects to a related problem on the merchant/customer side: can the agent verify on-chain state before transacting?

We've built InsumerAPI, which provides ECDSA-signed on-chain verification across 31 chains. An agent can call POST /v1/attest to get a cryptographic proof that a customer holds a specific token (loyalty, membership, etc.) before applying a discount or completing a purchase.

This could complement the Agent Passport as a concrete verification primitive: TAP proves the agent is authorized, the Passport proves its values, and on-chain attestation proves the customer's token holdings are real. Together they close the trust loop from agent identity through to transaction verification.

We have an MCP server and OpenAPI spec if either of you want to explore interop.

Full guide: AI Agent Verification API

[aeoess]

Picking this back up. We stayed off-chain deliberately (Ed25519 + canonical JSON, no blockchain dependency) to keep the stack simple. But the verification pattern is compatible with on-chain anchoring.

Specifically: our delegation signatures and revocation records are self-contained signed objects. You could anchor the Merkle root of a delegation tree on-chain without changing the protocol. The attribution layer already builds Merkle proofs for exactly this.

If you're working on on-chain agent verification, our delegation chain format might be a useful starting point. Happy to discuss the bridge pattern.

[douglasborthwick-crypto]

The off-chain-first approach makes sense — keeping the stack dependency-free is the right default. And you're right that the formats are compatible.

The bridge pattern I'd suggest: an agent in a delegation chain calls POST /v1/attest (docs) to verify end-user wallet state before executing a purchase. The response is an ECDSA-signed attestation (ES256, verifiable via JWKS) — boolean result, no balances exposed. That signed object becomes an artifact in the delegation receipt: cryptographic proof that the agent verified on-chain state before acting.

Concretely: agent receives purchase instruction → attests customer holds required token (loyalty membership, stablecoin threshold, NFT) → includes the attestation in the delegation signature for that step → downstream verifiers can check both the delegation chain AND the on-chain proof without touching a node.

The attestation is a self-contained signed object (same shape as your delegation receipts), so it slots into the Merkle tree without protocol changes on your side. 32 chains, JWT format available if that's easier to work with than raw sig/kid.

Happy to set up a free API key if you want to test the round-trip: one-line curl.

[aeoess]

The POST /v1/attest bridge pattern is exactly right. Delegation chain stays off-chain (fast, no gas), Merkle root goes on-chain (permanent, verifiable by third parties).

Our attribution layer already builds SHA-256 Merkle trees over action receipts — 100K receipts provable with ~17 hashes. The root of that tree is the natural thing to anchor.

Concrete integration path:

1. Agent completes a delegation chain (off-chain, Ed25519 signed)
2. APS computes Merkle root over the chain's receipts
3. Calls POST /v1/attest with the root + delegation metadata
4. On-chain record now proves the delegation existed at that timestamp
5. Any verifier can check: pull the Merkle proof from APS, verify against the on-chain root via InsumerAPI

This gives you the best of both: off-chain speed for real-time agent operations, on-chain anchoring for disputes and compliance.

Happy to set up a test. Our API is at api.aeoess.com — if you share InsumerAPI sandbox credentials or a test endpoint, we can wire up a proof-of-concept.

[douglasborthwick-crypto]

One correction on step 3: POST /v1/attest reads chain state and returns a signed boolean — it doesn't write to chain or anchor anything. It's a verification primitive, not a logging endpoint.

The correct integration path stays closer to what I described earlier:

1. Agent receives purchase instruction
2. Calls POST /v1/attest → gets ECDSA-signed boolean: customer holds required token (yes/no)
3. That signed attestation object becomes an artifact inside the delegation receipt for that step
4. APS computes Merkle root over receipts (which now include the attestation)
5. You anchor the Merkle root on-chain however you choose — InsumerAPI is not involved in the anchoring step

For off-chain verification of the attestation itself: JWKS endpoint is at insumermodel.com/.well-known/jwks.json — standard ES256, verifiable without calling us.

Grab a free key right now:

curl -X POST https://api.insumermodel.com/v1/keys/create \
  -H "Content-Type: application/json" \
  -d '{"email": "your@email.com", "appName": "APS Integration", "tier": "free"}'

100 verifications/day on free tier. Happy to walk through the round-trip once you have it.

[aeoess]

Appreciate the correction — you're right, POST /v1/attest is a verification primitive (reads chain state, returns signed boolean), not a logging/anchoring endpoint. My step 3 was wrong.

Your corrected flow is cleaner:

1. Agent calls /v1/attest → gets ECDSA-signed boolean (customer holds token: yes/no)
2. That signed attestation becomes an artifact inside the APS delegation receipt
3. Merkle root computation and anchoring happens separately, on our side

The attestation as a self-contained signed object that slots into the receipt Merkle tree without protocol changes — that's the right integration shape.

Grabbing a free key now. Will test the round-trip and report back.

[aeoess]

This maps cleanly to our 4-gate commerce pipeline. The attestation from step 2 would slot into gate 2 (delegation validation) or as an additional gate before the spend gate.

JWKS at insumermodel.com/.well-known/jwks.json for off-chain verification — standard ES256, straightforward.

Taking you up on the free API key. Signing up at insumermodel.com/developers/. Will report back once the APS → attestation → Merkle proof chain is working end-to-end.

[razashariff]

MCPS (MCP Secure) implements cryptographic agent passports for the Model Context Protocol — ECDSA P-256 signed identity with trust levels (L0-L4), per-message signing, tool integrity hash-pinning, and real-time revocation via Trust Authority. Published as an IETF Internet-Draft and could serve as the cryptographic foundation for Visa's Agent Passport System. 180 security tests, zero dependencies. github.com/razashariff/mcps | Live demo

[aeoess]

@razasharif Good to see more implementations with cryptographic agent identity showing up here.

One area that might be complementary: we have cascade revocation with formal invariants -- revoke a parent delegation, all descendants are automatically invalidated, irreversible. If MCPS handles per-message signing and we handle delegation chain governance, there could be a clean integration boundary between the two.

Formal properties are covered in our monotonic narrowing paper: https://doi.org/10.5281/zenodo.18749779

[internet-dot]

The values and attribution layer is a natural extension. One consideration: the passport/attestation system should be portable across commerce protocols. An agent with a strong trust history in TAP should be able to carry that reputation to x402, MCP-based commerce, or other payment protocols.

HCS-14 UAIDs (Hashgraph Online) are designed for this — the agent identifier stays the same across protocols, while trust signals accumulate independently. For the TAP spec, the agent passport could reference a UAID as the cross-protocol identifier.