Agentic Rails Atlasby merces.ai

Persona

Security researcher or red teamer

Breaks protocols and implementations, writes advisories.

Verified (verified under 30 days ago)

Role

Goals

  • Find flaws in the payment and identity protocols before attackers use them at scale.
  • Test real facilitators, SDKs and merchant endpoints against the safety rules each spec implies.
  • Model prompt injection as a payment attack: steer an agent to a different payee, amount or merchant inside its mandate.
  • Publish reproducible advisories with CVE identifiers and coordinated disclosure.
  • Build threat models that treat the LLM, the agent runtime and every intermediary as potentially hostile.

Pains

  • Specs are young and change monthly, so a finding against one dated version may not apply to the next, or may quietly reappear.
  • Proprietary terms (TAP, Agent Pay) restrict modification and sometimes testing, and reference code is read-only.
  • Facilitators and relays are centralized production systems, so testing them for replay or atomicity flaws needs careful scope.
  • Bearer credentials in MPP and ACP leak through logs and proxies, and vendors treat that as the integrator's problem.
  • Vendor sample code deviates from the standards it claims (RFC 9421 base construction, the 8-minute window), and that code ships into merchants.
  • Disclosure contacts for foundations and consortia are unclear, and some have no security policy.

Decisions they own

  • Which protocol or implementation to target next, and which attack classes to prioritize (replay, atomicity, signature coverage, injection).
  • Disclosure timeline and whether to publish a proof of concept.
  • Whether to request a CVE or rely on a GHSA or vendor advisory.

Vocabulary

  • replay
  • nonce
  • signature coverage
  • atomicity
  • prompt injection
  • bearer token
  • CVE
  • GHSA
  • threat model
  • proof of concept
  • coordinated disclosure
  • free-riding
  • voucher bypass
  • requestHash squatting

Each protocol from this seat

Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.

ERC-8004: Trustless Agents

Relevance: High

Studies the registries, the deployed proxies and the feedback data for attacks and failure modes. Source [1, 2, 3, 4, 5]

Goals

  • Measure Sybil feedback and placeholder registrations
  • Find contract and governance weaknesses
  • Publish reproducible findings

Pains

  • No named audit report
  • No public log query over large block ranges on free RPCs
  • Values with no common unit

Implements

  • Event crawls and census-style probes
  • eth_call reads of owner and implementation slots
  • Graph analysis of reviewers

Must trust

  • RPC providers and indexers
  • The census and study methods it reuses
  • Its own detection heuristics

Questions they ask

  • Who holds the upgrade key?
  • How much feedback is grounded in payment?
  • Can requestHash squatting block validation?

First three steps

  1. Read the Security Considerations and PR 51
  2. Read owner() on the three proxies
  3. Reproduce the arXiv:2606.26028 liveness measure on one chain

Metrics they care about

  • Share of live agents
  • Share of Sybil reviewers
  • Open issues without a fix

A day in the life. Priya reads the proxies on Ethereum and Base and finds one externally owned account owning all three, with no published holder. She checks the community audit in PR 51, still unmerged, and confirms from the code that a validator can lower a pass and that a requestHash can be claimed first by anyone. Then she samples feedback: most reviewers rate many agents with identical values within minutes, the same pattern arXiv:2606.26028 reported. She writes it up with dates and block numbers, because every one of these facts can change with an upgrade.

Steps in the responsibility table

  • ObservesWrite and host the registration file
  • ObservesRegister the agent (register)
  • ObservesWrite feedback with proofOfPayment
  • VerifiesChoose trusted reviewers for getSummary
  • VerifiesAnswer validation requests (specified only)
  • ImplementsWatch transfers, URI changes and upgrades

x402

Relevance: None

Not one of the main personas on the x402 page. The responsibility table gives this persona no step.

Visa Trusted Agent Protocol

Relevance: None

Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.

Agentic Commerce Protocol (ACP)

Relevance: None

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: None

Not one of the main personas on the UCP page. The responsibility table gives this persona no step.

AP2

Relevance: None

Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.

Mastercard Agent Pay

Relevance: None

Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.

Sources

  1. On-chain reads of the ERC-8004 proxies (owner, getVersion, ERC-1967 implementation slot) on Ethereum and Base (external link)Atlas research (eth_call through public RPCs). Dataset, primary source. Accessed .
  2. Security Audit: Fix response downgrade vulnerability + comprehensive report (PR 51) (external link)erc-8004 (GitHub organization), community contributor saiboyizhan. Repository. Published . Accessed .
  3. ValidationRegistryUpgradeable.sol (external link)erc-8004 (GitHub organization). Repository, primary source. Accessed .
  4. Rogue validators can manipulate validation response values (issue 28) (external link)erc-8004 (GitHub organization). Repository, primary source. Published . Accessed .
  5. Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem (external link)arXiv (Xiong, Li, Wei, Wang et al.). Paper, primary source. Published . Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts