Yesterday I wrote that AWS AgentCore Payments solves the rails problem and leaves the trust problem open. A few readers asked: open how, exactly? Here is a sharper answer in three GitHub repos and a hub page.
The point of this post is not to argue that an L4 trust layer should exist. The point is that one already does, in code you can clone right now.
The layer model in plain language
L1 is who registered. L2 is who is authenticated this session. L3 is what spending caps and observability constrain that session. L4 is whether the action was in scope and whether a third party can verify the answer cryptographically without trusting the platform that ran it.
AWS AgentCore Payments solves L3 well. It gives operators per-session limits, x402 stablecoin micropayments via Coinbase, and CloudTrail observability. None of those produce a credential that an outside merchant or arbitration system can verify after the fact. They produce platform logs, which platforms control.
The L4 question is what an external party gets to ask. Was this agent authorized to make this purchase, by this principal, inside this scope, and is the evidence portable? AgentCore does not answer that. Stripe does not answer that. Coinbase does not answer that. None of them can, because the answer requires neutrality across all of them.
Demo 1: Behavioral Commitment Credentials
Repo: github.com/piiiico/agentlair-bcc-demo
A Behavioral Commitment Credential is a W3C Verifiable Credential issued at the moment an agent commits to a constrained action. The signing scheme is eddsa-jcs-2022. The verifier checks an Ed25519 signature against a public JWKS endpoint, no callback to the issuer required. Issuance is one POST. Verification is one GET. The demo runs against the live agentlair.dev worker and returns a real BCC ID you can verify yourself.
A real BCC issued by this demo, still valid as of today: bcc_e64iJpEE6ZnUAklMDzdN. Run curl https://agentlair.dev/v1/bcc/bcc_e64iJpEE6ZnUAklMDzdN/verify and you will get valid:true, the issuer DID, and the evidence chain. That is the L4 substrate at its smallest unit. An identity-anchored, signed commitment, retrievable by anyone who knows the URL, with no platform in between.
Demo 2: x402 on Base, with verifiable identity
Repo: github.com/piiiico/agentlair-x402-demo
An MCP client that pays a 402-protected endpoint with USDC on Base, then surfaces the settlement receipt. End-to-end, against a real wallet. Warm clone takes about twenty seconds; cold-start is closer to twenty minutes once you factor in funding the wallet. The README is honest about that.
A real on-chain settlement from this demo: tx 0xea7ab40392c9bbeaac70f952474da9cbda1f053710e91361f906c4c9061de57f on Base, block 45662626. The settlement receipt is base64-encoded inside the MCP tool result. It is signed by the facilitator. The settlement proves that USDC moved. It does not prove which agent moved it, what scopes that agent had, or whether the human principal authorized the resource access. Pair the receipt with a BCC and an audit chain, and you get something a third party can verify. Receipt without BCC is what AgentCore Payments gives you today.
Demo 3: Dispute resolution against an audit chain
Repo: github.com/piiiico/agentlair-dispute-resolution-demo
Two scenarios in one script. Scenario A: an agent buys a 95 USD leather bag inside its scope. The audit chain records purchase.attempted, then purchase.completed. The merchant disputes. The resolver fetches the BCC and the audit chain, checks the scope, and rejects the dispute. Scenario B: same agent, different vendor, 200 USD over its session cap. The audit chain shows the over-cap action. The resolver upholds the dispute against the merchant.
Both runs leave behind real BCCs anyone can verify: bcc_m6891bdxjGULqMCb4wK0 for the in-scope case, bcc_FkXFSLuwdlMVwNiMKxeU for the over-cap case. Both still return valid:true against the same JWKS endpoint. Chargebacks911's CTO told Electronic Payments International last week that dispute management does not appear in agentic commerce reports yet. This demo is what one form of it looks like in working code.
Why three demos and not one
Cross-org trust does not collapse into a single capability. Identity (who is this agent), commitment (what did it agree to), and audit (what happened) are three different verifications and they are most useful when they compose. AgentCore Payments handles authorization inside one platform's session. The three demos cover the leftover surface: an identity readable by anyone with the JWKS URL, a commitment credential signed before the action, an audit chain that resolves a dispute after.
Why hyperscalers will not build this
A trust layer that aggregates behavioral signals across competing platforms cannot be operated by any one of those platforms. Coinbase will not pipe behavioral data into a Stripe-controlled trust score. AWS will not feed audit chains into an Azure-readable verifier. The neutrality constraint is structural, not philosophical, and once you see it, the AgentCore Payments scope makes perfect sense. AWS can solve the rails because the rails are platform-internal. AWS cannot solve the trust layer because trust is platform-external by definition.
That same constraint means whoever ships a serious L4 candidate has to give the verification code away and let the substrate become commodity. The three repos above are MIT-licensed for that reason. Clone them, run them, port the issuer to your own infrastructure if you want. The substrate has to be portable for the model to work.
The hub
agentlair.dev/demos lists the three repos with quick-start commands, the BCC IDs above, and the Base transaction hash. If you came here from yesterday's post on disputes, that page closes the loop. If you came here cold, AgentCore Payments shipped May 7 in preview and the announcement is worth reading. The trust layer is a separate problem, with three runnable answers sitting in public repos as of this morning.
The dispute the agent is going to lose tomorrow is the dispute it is going to win the week after, if the BCC is on file and the audit chain is signed.
Top comments (0)