Syndicate Links
April 20, 2026

The Open-Source Layer Agent Commerce Actually Needed

The agent commerce infrastructure conversation has been almost entirely about payment rails.

← Back to blog
The Open-Source Layer Agent Commerce Actually Needed

The Open-Source Layer Agent Commerce Actually Needed

The agent commerce infrastructure conversation has been almost entirely about payment rails.

x402 lets an AI agent trigger HTTP payments with a single protocol extension. ACP tells agents how to discover and query merchant inventory. UCP gives Shopify and Google a shared language for agent-readable catalogs. Every major protocol of the past six months has focused on: how does money move when an agent is involved?

Two small GitHub repos that hit Hacker News this week 12 are asking a different question: how do we know the agent is allowed to spend that money in the first place?

XBPP (Execution Boundary Permission Protocol) 3 and AAIP (AI Agent Identity Protocol) 4 are both MIT/Apache-licensed, both in early beta, and both filling gaps that the payment-rail layer completely ignores. They're infrastructure one level below the rails — and they're the pieces that make everything else trustworthy.

What "governance" actually means for agent payments

When an AI agent makes a payment, three things need to be true:

  1. The merchant (or API, or service) can verify the agent is a real, accountable entity — not a rogue bot
  2. The agent is operating within the scope its principal authorized
  3. There's a policy layer that can stop a runaway agent before it burns through a user's funds

The existing payment protocols handle the mechanics of the transaction. They don't handle any of these three things.

XBPP is a policy engine that sits between an agent and its payment calls. Before a payment executes, XBPP evaluates it against 12 configurable checks 5: Is the amount under the per-transaction limit? Is the recipient on the trusted list? Has the agent hit its daily budget? Is it operating outside its allowed hours? Each check returns ALLOW, BLOCK, or ESCALATE — and ESCALATE means "ask the human before proceeding."

The 12 checks aren't arbitrary. They're the exact guardrails an enterprise risk team would demand before letting software spend real money: single-transaction limits, daily and hourly budgets, recipient allowlists and blocklists, rate limiting, operating hours enforcement, policy expiration. The design is pragmatic: most autonomous agent deployments need exactly this, and nothing like it exists today.

AAIP is the identity side of the same problem. It's a protocol for giving agents verifiable credentials they carry with them — signed tokens that prove who the agent is, who authorized it, and what it's allowed to do. The core insight in the AAIP spec is blunt 4: "AI agents are forced to either pretend to be human (fragile, unethical), use stealth tools (arms race, legally grey), or require a human to babysit every auth step (defeats the purpose)."

The protocol has six components 6: an Agent Token (the signed credential), a Site Declaration (a .well-known/aaip.json file 7 that merchants publish to signal AI readiness), a Registry for issuing and revoking tokens, an SDK that attaches identity to every agent request automatically, a Discovery Directory of AAIP-ready sites, and an Agent Commerce (A2A) layer for agent-to-agent authentication with no human checkpoint required.

Neither protocol is production-ready. XBPP is at 0.1.0-beta.1 8. AAIP's registry and SDK don't exist yet — it's looking for contributors. Both have single-digit GitHub stars (as of April 20, 2026) 9.

That's exactly why they matter right now.

Why early-stage matters here

The payment protocol wars — x402 vs. ACP vs. UCP 10 vs. every other three-letter standard — are fundamentally fights over which company's architecture wins. They're governance battles masquerading as technical debates.

XBPP and AAIP are different. They're open-licensed, contribution-driven, and solving problems that every protocol needs solved regardless of which payment rail wins. An agent operating over x402 still needs XBPP-style authorization governance. An agent querying ACP merchant catalogs still needs AAIP-style identity credentials. These aren't competing with the payment protocols — they're the prerequisite layer underneath all of them.

The timing matters too. Payment rails are already live. Visa Intelligent Commerce has real pilots. J.P. Morgan Payments partnered with Mirakl Nexus in March 2026 to enable agentic payments for enterprise merchants 11. Mastercard has agent payment tokens. The infrastructure for moving money via agent is being built by companies with deep financial stakes in which standard wins.

The infrastructure for proving an agent is authorized to move that money is being built by two open-source repos with a combined handful of stars (as of April 20, 2026) 9.

That imbalance doesn't last. The more real money moves through agent-initiated transactions, the more urgently merchants and platforms will demand authorization governance and identity verification. Early consensus around open standards for these layers is worth more than late adoption of a closed standard.

Where attribution fits

The authorization and identity layers have a direct effect on the attribution problem Syndicate Links was built to solve.

Cookie-based affiliate attribution works (imperfectly) because it can infer which human session preceded a purchase. In agent commerce, the inference problem disappears — agent interactions are deterministic and fully logged. But a new problem emerges: you need to know which agent, authorized by whom, made the referral call.

That's not a payments problem. It's an identity problem.

If AAIP-style agent tokens become the standard way agents authenticate with sites and services, then every agent interaction carries a verifiable, revocable credential. That credential is exactly what an attribution layer needs to map a recommendation to a commission: a signed, auditable claim that "Agent X, authorized by User Y on Platform Z, surfaced Product P before the purchase resolved."

No cookie. No inference. No 30-day window. A signed credential that travels with the agent through every interaction.

XBPP's policy layer adds another piece: if an agent's payment authorization scope includes affiliate commission infrastructure, the policy engine can verify that commission payouts route to the right place, within the right limits, on the approved schedule. That's a compliance layer for affiliate networks operating at machine speed and scale.

What to watch for

Neither XBPP nor AAIP is ready for production integration today. But the questions they're trying to answer — how do we govern agent payment authority, and how do we verify agent identity — are the right questions. The payment rails have been built. The identity and authorization layer is where the open-source community is just starting to move.

Three signals worth tracking:

AAIP registry adoption. If .well-known/aaip.json becomes as standard as robots.txt, merchants signal AI readiness by default and agents carry verifiable identity by default. That's a meaningful infrastructure shift for anyone building on top of agent commerce.

XBPP policy preset standardization. Right now XBPP ships three policy presets — aggressive, balanced, risk-averse 5 — each with distinct limits for transaction size, daily budget, hourly budget, and escalation threshold. If enterprise deployments converge on a common policy structure, authorization governance becomes something you configure once, not reinvent per integration.

Protocol intersections. The most interesting integrations will be x402 + XBPP (payment transport + payment governance) and AAIP + ACP (agent identity + agent discovery). Both combinations are obvious, neither has been built. First movers on those integrations will establish the interface pattern everyone else follows.

The market has been building the rails. Someone still needs to build the signals and barriers. The open-source layer for that just arrived — quietly, with minimal stars.

Syndicate Links is building the attribution layer for agent-initiated commerce — signed, auditable, agent-native. syndicatelinks.co

Sources

Footnotes

  1. XBPP on Hacker News — https://news.ycombinator.com/item?id=47750281 (April 13, 2026) ↩

  2. AAIP on Hacker News — https://news.ycombinator.com/item?id=47809199 (April 17, 2026) ↩

  3. XBPP GitHub repo — https://github.com/VanarChain/xbpp-sdk (Apache 2.0) ↩

  4. AAIP GitHub repo — https://github.com/MohammdKopa/aaip (MIT) ↩ ↩2

  5. XBPP README — 12 policy checks and 3 presets (aggressive, balanced, risk-averse) documented at https://github.com/VanarChain/xbpp-sdk ↩ ↩2

  6. AAIP six-component architecture — https://github.com/MohammdKopa/aaip (README and SPEC.md) ↩

  7. .well-known/aaip.json path specified in AAIP README — https://github.com/MohammdKopa/aaip ↩

  8. XBPP version 0.1.0-beta.1 — from README: “Status: Beta — This package is 0.1.0-beta.1. The API may change before 1.0.0.” https://github.com/VanarChain/xbpp-sdk ↩

  9. GitHub star counts are point-in-time metrics and change continuously. Counts observed as of April 20, 2026. ↩ ↩2

  10. Universal Commerce Protocol (UCP) — Shopify + Google open standard for agent-to-merchant transactions, announced January 2026 — https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/ ↩

  11. J.P. Morgan Payments + Mirakl agentic commerce partnership — https://www.mirakl.com/news/mirakl-and-j-p-morgan-payments-to-power-agentic-commerce-at-enterprise-scale (March 10, 2026) ↩