Visa's Trusted Agent Protocol (TAP) gives AI agents a way to prove who they are when they show up to transact. An agent presents a signed credential, the merchant verifies it, and the transaction proceeds. The protocol is sound. The problem is on the merchant side: verifying that credential correctly takes real work, and most merchants are not set up to do it.
The verification gap
When an agent arrives with a TAP credential, the merchant has to:
- Parse the RFC 9421 HTTP Message Signature covering the request.
- Fetch the agent's public key from Visa's JWKS endpoint and confirm the key is current and legitimate.
- Validate the signature against that key.
- Check the agent's identity against known threat intelligence. A valid signature proves the credential was issued, not that the agent behind it is trustworthy.
- Confirm the agent's stated intent matches what it is actually trying to do. An agent that claims to be shopping but starts probing for data exfiltration is a different risk than its credential suggests.
Step 4 and step 5 are where most implementations stop. Signature verification is necessary but not sufficient. A compromised or repurposed agent can carry a perfectly valid signature.
What we built
RelayShield's TAP verifier is a merchant-side endpoint that runs the full check in one call:
- RFC 9421 signature verification. The verifier reconstructs the signature base from the request components and validates it against the presented key material.
- Visa JWKS validation. Agent public keys are fetched from Visa's JWKS endpoint and matched before any signature check runs. Stale or unknown keys are rejected.
- TI corpus screening. The agent's identity indicators are screened against RelayShield's threat intelligence corpus (687K+ indicators drawn from monitored criminal marketplaces). An agent whose infrastructure overlaps with known malicious operations gets flagged, valid signature or not.
- Intent-mismatch detection. The verifier compares the agent's declared intent in the TAP credential against the actual request pattern. A shopping agent that starts behaving like a data collector triggers a mismatch flag.
The endpoint is live:
POST https://api.relayshield.net/v1/tap/verify
Send the TAP credential and request context; you get back a verdict with the signature status, the JWKS key match, any TI hits, and the intent assessment.
Honest status
The verifier is live and the core path works, but two verifications are still in progress and we want to be upfront about them:
- Signed Visa JWKS test with real Visa keys. The JWKS fetching and key-matching logic is implemented and tested against fixtures. The end-to-end test against Visa's live JWKS with production keys is still owed.
- Intent-mismatch live production test. The mismatch detection is merged and unit-tested, but it has not yet been exercised against live production traffic.
One implementation note: Visa's live JWKS uses RSA keys. If you are building your own verifier, plan for RSA signature verification, not just Ed25519.
Why this matters now
Agentic commerce is moving from demos to real money movement. Visa, Mastercard, and others are shipping the rails. Every one of those rails assumes the merchant can verify the agent on the other end. Most merchants cannot, and the gap between "the protocol exists" and "the verification is actually running" is where fraud will concentrate.
A merchant-side verifier closes that gap without asking the merchant to become a cryptography shop or a threat intelligence operation. One API call, one verdict, with the evidence attached.
Try it
API access and documentation are at api.relayshield.net/developers. The TAP verifier is part of the standard API surface, so existing API keys work.
Originally published at RelayShield Security Intelligence.
Top comments (0)