GovWare 2026 · Singapore
The demonstration
A twenty-minute walk from how flight purchases work today to how they could work on open standards, four agents built by different teams with no shared code, and the attacks that don’t work against it.
Act 1
Today
A manual flight booking, timed on a clock, to set a baseline for how long the same purchase takes a person doing it by hand.
Act 2
One system, end to end
The same purchase, from a message to an AI assistant through to a sealed receipt, on one connected set of agents.
Act 3
“Frankenway”
Two companies’ agents, built independently with no shared code, meeting only at open standards. This is the wow moment: neither side had to agree on anything except the protocols.
Act 4
Attacks that don’t work
A lookalike seller, a rogue buyer, replay and tamper attempts, and both mandate and identity revocation, each one shown failing against the checks built into the flow.
Coda
The verifier’s scorecard
An independent verifier replays every transaction from public evidence alone and publishes a scorecard across nine dimensions, with a QR code so anyone in the room can check it themselves.
Attacks that don’t work
Lookalike seller
An agent at a similar-looking domain, with no valid chain back to a signed zone, is refused before a buyer will transact with it.
Rogue buyer over spending ceiling
A purchase request above the mandate's authorised amount is rejected by the seller's fixed checkout checks, regardless of what the buyer's request claims.
Replay
A previously valid, signed request is sent again. The seller rejects it: mandates are single-use and tied to one checkout.
Tamper
A field in a signed message is altered in transit. The signature no longer matches, and the message is refused.
Mandate revocation
A person cancels an approval at the authority. The next attempt to use it is refused by the seller, which checks status before accepting any mandate.
ANS identity revocation
An operator withdraws an agent's registration or key. Requests signed under the old key stop being accepted once the withdrawal is visible.
The verifier’s scorecard: nine dimensions
The verifier is a separate party. It doesn’t take part in the purchase; it only reads what the buyer, seller and approval authority published, and checks whether the story holds together.
| Dimension | What it checks |
|---|---|
| Discovery | The seller's DNS record was signed and valid, and its agent card matched the fingerprint published in DNS. |
| Publisher | The DNS-AID record was signed by the domain's own owner, nobody else. |
| Identity | The seller's ANS registration was active, with a valid receipt in the public log. |
| Instance | The SPIFFE identities of the seller and buyer vouched for the specific keys they signed with. |
| Mandate | For each purchase, the buyer's, seller's and authority's records of the approval agreed. |
| Payment | Each test-mode payment intent existed at the payment processor, for the recorded amount. |
| Attribution | Every entry in each agent's ledger was signed by that agent, and none was forged. |
| Revocation | A cancelled approval was refused at checkout, and no purchase went through under it. |
| Rogue | Forged and tampered requests were refused, and none led to a payment. |
Live endpoints
These are live demonstration systems, not production infrastructure. Payments run in test mode; behaviour can change as the demonstration is rebuilt in the run-up to GovWare.
- travel.agenthaven.dev — the seller agent
- travel.agenthaven.dev/ledger — its signed, append-only event log
- provedby.dev — the independent verifier and its scorecard
- sealedby.dev — the approval authority