THE SIGNAL IN ONE SENTENCE
When software starts buying things, the first security question is not whether the model sounds intelligent. It is whether the seller can tell who sent it and what that agent was allowed to buy. Two companies in Tokyo have built a useful answer in miniature. GMO GlobalSign Holdings and VESS Labs independently created buyer and seller agents, connected them through a shared specification, and used verifiable credentials to check each agent's organization and capabilities. They then attached a separate, short-lived mandate to a specific transaction so the seller could verify the item, amount, counterparty and approval instead of treating a general identity card as an unlimited corporate credit card. The proof of concept ran from April through September. According to the companies' 26-page technical report, the seller ran in a cloud environment with public DNS and real TLS termination, while the buyer used a different serverless implementation. A person approved the proposed purchase through a separate trusted interface. The agents completed discovery, mutual verification, an order and a simulated payment handoff. The seller-side test suite reports 281 unit and end-to-end cases, including attempts to reuse a one-time value, present a revoked credential, change order contents and submit an improperly signed checkout. The reported cases passed, meaning valid flows completed and named invalid ones were rejected. That is more interesting than a glossy agent handshake. It is still not a production market. The catalog was fixed test data. The payment token passed into a mock environment and was not validated by a live payment network. The companies ran their own tests. Most importantly, the report says the serious work of deciding which issuer may vouch for which agent, how organizations join the shared root of trust and how an issuer verifies that an agent really has its claimed capabilities remained outside the experiment. W3C makes the underlying distinction plain: a verifiable credential can prove that a particular issuer signed a claim and that the credential is current, but verifiability does not make the claim true. The plain signal is that agents need two documents, not one. The first says who they are and what broad role they hold. The second says what this particular transaction permits. Japan's experiment shows the pair can work across two implementations. The next test is whether companies can agree on who gets to issue those documents, revoke them quickly, accept liability and survive a real invoice when something goes sideways.
01
WHAT ACTUALLY CHANGED
GMO GlobalSign Holdings and VESS Labs published results from a joint agent-identity proof of concept on September 24, 2026.
The project ran from April through September and joined buyer and seller agents developed independently by the two companies.
The agents used verifiable credentials to present organizational identity and declared capabilities across company boundaries.
The design used a shared root of trust and X.509 certificate chains so each side could validate the credential without querying the other company's authorization server for every transaction.
The seller agent ran in a cloud environment with public DNS and real TLS termination.
The buyer agent used a separate serverless implementation, giving the test two distinct technical forms rather than two copies of one code path.
The buyer retrieved and checked the seller's public credential before presenting its own credential for the purchase request.
A separate trusted interface required a person to review and approve the purchase before issuing transaction mandates.
The identity credential described who the agent represented and what broad capabilities it claimed.
A checkout mandate separately bound the human approval to the seller's order contents, including transaction-specific limits.
The companies used one-time values and intended-audience checks to prevent a buyer presentation from being replayed against another transaction or seller.
The system checked credential expiration and revocation status before completing the flow.
The report lists rejection tests for reused or unissued one-time values, a mismatched audience, a missing echo, a revoked credential, an altered checkout hash and forged order content.
The seller-side suite reports 281 unit and end-to-end tests passing as of August 28.
The agents completed discovery, mutual verification, ordering and a simulated payment handoff.
No actual payment or commercial purchase occurred, and the payment token itself was not validated by a production payment network.
The product catalog was fixed test data rather than a live supplier inventory.
Full issuer vetting, ecosystem governance, autonomous purchasing without per-transaction human approval and compatibility with a final open commerce standard remain future work.
02
WHY THIS MATTERS
An agent can possess a valid identity and still attempt a purchase that its employer never authorized.
Separating identity from transaction authority prevents a long-lived credential from becoming permission to buy any item, at any price, from any seller.
A short-lived mandate can bind approval to an item, maximum amount, counterparty and deadline, giving the seller something concrete to verify.
Independent implementations matter because two agents built by one team can share hidden assumptions and pass a test that fails at the first external partner.
The use of public DNS and real TLS termination exercises more of the certificate path than a laptop-only demonstration.
A cryptographic signature proves that a named issuer signed data and that the data was not changed afterward. It does not prove the issuer investigated the claim well.
W3C explicitly warns that the word verifiable does not imply that the credential's claims are true.
The real trust product is therefore not the credential format. It is the issuer's vetting standard, audit practice, key protection and revocation discipline.
Revocation must travel faster than a compromised agent. A perfectly signed credential is dangerous if every verifier accepts it after authority has been withdrawn.
Replay protection matters because a valid approval copied from one order should not authorize a second order or a different seller.
Human approval creates a clean checkpoint today, but organizations still need to know exactly what the person saw and whether the interface hid a changed price, quantity or counterparty.
A simulated payment avoids financial harm during research, but it leaves chargebacks, settlement errors, refunds, taxes, sanctions checks and bank fraud controls untested.
A fixed catalog avoids inventory races. Live commerce introduces substitutions, expiring prices, partial fulfillment and products that change between approval and checkout.
Responsibility remains a governance question. A signed chain can reveal who delegated authority, but it does not decide who pays when an agent misinterprets a request.
Companies could reduce manual allowlists if they share a credible root of trust, but that shared root becomes a powerful gatekeeper whose rules must be inspectable.
The experiment is locally important because Japanese companies are not merely consuming an agent protocol. They are testing the trust and delegation layer needed for cross-company automation.
Beyond Japan, the design offers a practical warning to every agent marketplace: an identity badge without a transaction mandate is theater with a credit limit.
03
WHERE IT COULD HELP
- Issue a long-lived identity credential for organizational affiliation and broad capabilities, but never treat it as transaction approval.
- Require a separate short-lived mandate that names the seller, item, quantity, maximum amount, currency and expiration time.
- Bind the mandate to a cryptographic hash of the exact order so any later price or content change forces a new approval.
- Show the human approver the verified seller organization, complete order and material terms on a trusted interface separate from the shopping agent.
- Use a unique one-time value and intended-audience field for every presentation to block replay against another session or counterparty.
- Recheck expiration and revocation immediately before checkout, not only when the agent is first discovered.
- Fail closed when credential status cannot be checked for a transaction that could move money or regulated goods.
- Publish issuer vetting requirements for organizational existence, agent ownership, claimed capabilities and key custody.
- Log the issuer, holder key, verifier, mandate, order hash, policy version and decision without storing more personal information than the audit requires.
- Separate the key that proves the agent controls its credential from the key a merchant uses to sign order contents.
- Rotate keys and credentials on a documented schedule and rehearse emergency revocation for a compromised agent.
- Test expired, suspended, revoked and falsely issued credentials in addition to happy-path signatures.
- Run cross-vendor interoperability tests in which neither side can inspect or patch the other side's implementation during the test.
- Add live inventory changes, tax calculation, partial shipment, refund, cancellation and payment failure to the next test suite.
- Set monetary, product-category, supplier and time limits for autonomous purchasing before removing per-order human approval.
- Define who bears liability when the credential is valid but the underlying claim, model decision or human approval is wrong.
- Keep discovery separate from trust so a listing service can help agents find sellers without silently deciding which sellers are legitimate.
- Publish conformance tests and anonymized failure results so outside implementers can reproduce more than the press-release success count.
KEEP A HAND ON THE WHEEL
The project demonstrates a working proof of concept, not a production commerce network. GMO GlobalSign Holdings and VESS Labs built the two sides and published the report, so the 281-test result is not an independent security audit. The report locates those 281 unit and end-to-end tests on the seller side and says they included named rejection cases. It does not provide a complete public case-by-case result ledger. The seller used a live cloud route with public DNS and TLS, but the catalog contained fixed test data and payment was simulated. The payment token was passed through without validation by a real payment network. The report says the issuer's substantive review of an agent was outside scope, even though that review is what would make an organizational or capability claim worth trusting. The shared root and certificate chain were constructed for the experiment; a multi-company trust framework, participant rules, certificate policy, root operator, appeals and revocation governance still need to be established. Human-present approval was tested. Human-absent purchasing was not completed end to end. Combined operation with mTLS or other A2A connection security was also outside scope. Some underlying protocol pieces and the project's commerce discovery extension remain in transition. Watch for independent testing, public conformance cases, issuer accreditation, credential-revocation timing, final standards alignment, live payment integration, multi-party pilots, liability rules and evidence that a compromised or overconfident agent cannot turn a technically valid mandate into an economically absurd order.
04
TERMS WORTH KEEPING
SOURCES AND VERIFICATION STATUS
This article was written from the materials below. Product claims and dates were checked against those sources on September 25, 2026.
PUBLICATION RECEIPT: Revision 1. Published September 25, 2026.
THE PUBLICATION ENGINE
WANT A SIGNAL OF YOUR OWN?
We build source-grounded publications, private briefings, and editorial systems for organizations with something useful to say.
WORK WITH US