TBN Protocol · Multiplayer Agent Sessions

One agent. Many humans. Every action, receipted.

Multiple people join a single shared AI agent session — and every message, decision, and action the agent takes is bound to a cryptographic receipt. Not a log you have to trust. A receipt you can check.

See the demo How it works

The demo below is illustrative and runs entirely in your browser. It does not connect to a live session or issue real credentials.

What We Built

A Shared Agent, Not A Shared Log

Normally an AI agent talks to one person. A multiplayer session lets several people share one agent and one conversation — a support call with two colleagues, a negotiation with two counterparties, a review with an approver and a requester. Everyone sees the agent's reasoning, and every consequential action is checked before it happens, not audited after.

01
Create or Join

One person opens a session and gets a session ID. Anyone with that ID can join as a named participant. The agent is shared, not duplicated per person.

02
Every Action Gets a Receipt

Before the agent does anything beyond talking — updating a record, sending something, taking a consequential action — it must hold a valid receipt naming the exact action, target, and who authorized it.

03
Wrong Receipt, No Effect

A receipt for the wrong action, wrong target, or an expired receipt is refused before anything happens. Enforced by the binding check, not by the agent's judgement.

Illustrative Walkthrough

Alice and Bob, One Session

This reconstructs, in miniature, what a real session produces: two participants, a shared agent, a plain-language transcript, and a receipt behind every action. Click a receipt tag to inspect it. Nothing here is live — this is a fixed illustrative script, not a connection to any running system.

🛡️

TBN Multiplayer Agent Session

ONE AGENT · MANY HUMANS · LIVE · PROVABLE
EVERY LINE ABOVE IS A SYNTHETIC EVENT GENERATED IN YOUR BROWSER, STYLED TO MATCH THE FORMAT OF A REAL TBN MULTIPLAYER SESSION: NUMBERED EVENTS, A DRIVER TAG, AND AN RSA-SIGNATURE MARKER PER LINE, PLUS A SIGNED HASH CHAIN SUMMARY AT THE BOTTOM. CLICK ANY RSA-SIGNED MARKER TO SEE WHAT THE SIGNATURE ACTUALLY COVERS. CLICK 🔏 approval_context_hash TO SEE WHAT AN APPROVER ACTUALLY HAD IN FRONT OF THEM AT THE MOMENT THEY APPROVED — NOT JUST WHO CLICKED APPROVE. CLICK 🚫 refusal logged OR ↩ followup recorded TO SEE THAT A DECLINE IS A DURABLE, JOINED RECORD RATHER THAN A DEAD END. NO REAL BOT ID, SIGNATURE, HASH CHAIN, APPROVAL, OR REFUSAL RECORD IS PRODUCED, AND NOTHING HERE CONNECTS TO ANY LIVE SESSION.
The Trust Model

No Receipt, No Effect

"Wrong action, wrong target, wrong surface, wrong tier, or an expired receipt means no effect — regardless of what the agent or any participant intended."

Decision Tiers
Every action is classified before it runs: Tier 1 reversible (read, list, search), Tier 2 state-changing (update a record), Tier 3 consequential (transfer, delete), Tier 4 irreversible (deploy, bulk delete).
Hold → Bind
A Hold token is issued first: it cannot execute anything, and exists purely for human review. Only after review does a Bind receipt get issued, and only a valid Bind receipt can trigger an effect.
Binding Hash
Each receipt's binding hash is computed over the receipt ID, the exact action, and the exact target. If any of those three don't match at execution time, the binding check fails and nothing happens.
Consuming Failures
Security-relevant failures — forged attestation, replay attempts, wrong action or target — consume the receipt so it cannot be retried. Ordinary failures like a downstream timeout do not.
Clawback
A separate clawback record can be issued against a past receipt, citing the original receipt ID and a reason, without silently rewriting history.
Approval Context Hash
An approval binds not just who approved, but a hash of exactly what was rendered to them at that moment — the session state, prior turns, other participants' actions. Authority and informed authority are two different claims; this makes both provable.
Refusal Log
A hard refusal is written as a durable, signed record rather than a dead end in the transcript. Whatever happens next — override, escalation, or nothing — is appended to that same record, so the audit trail isn't silent exactly where it matters most.
Questions

Before You Ask

Is the demo above connected to a real system?

No. It runs entirely in your browser using JavaScript embedded in this page. The session, the participants, the transcript, and the receipts are all fixed illustrative content. No network request is made to any TBN service, and no real credential is issued.

What does a real receipt actually prove?

That a specific action, on a specific target, under a specific authority, was checked against a binding hash before it was allowed to take effect — and that a wrong or expired receipt is refused rather than silently accepted. It proves the check happened, not that the underlying business decision was correct.

Can more than two people join a session?

The model is not limited to two. This page uses Alice and Bob because two participants are the clearest way to show the shared-agent, per-action receipt pattern.

Is this a certification or compliance guarantee?

No. This describes an internal governance mechanism, not third-party certification or accreditation of any kind.

Talk to Us

Ask us about multiplayer agent sessions.

Tell us what you're trying to build with a shared, governed agent session, and we'll get back to you. Or skip the form and email us directly.

info@hardinai.co.uk

This form does not submit anywhere on its own. Pressing send opens your default email application with a pre-filled message addressed to info@hardinai.co.uk — nothing is transmitted until you actually send that email yourself. No data from this form is stored or sent to any server.