T3
Terminal 3
Enterprise Claw · Live Demo
Step 00 / 11
Agent View
travelhub.example / hotels
TravelHub
A Terminal 3 demonstration

An agent that cannot leak what it cannot hold.

Watch an enterprise travel agent book a hotel in Tokyo, end to end, while never holding a single credential it could lose.

Agent identity via W3C DIDs Execution inside TEE Audit on Merkle ledger
The starting point

The agent carries its rules with it.

A Smart Verifiable Credential, issued by Acme Corp through Agent Auth, defines what this agent is allowed to do. The policy travels with the request. The constraints on the left are not a UI suggestion. They are cryptographic.

←
refer to the agent panel
Destination
Tokyo, Japan
Area
Shinjuku
Check-in / out
20 Jun → 24 Jun
Guests
1 adult
128 stays in Shinjuku
unsorted · all ratings
Shinjuku
Map
All amenities
5 stays in Shinjuku
no VC filters yet
Shinjuku
4 star minimum
USD 200 / night max
non-smoking
sorted by rating ↓
VC constraints applied
3 of 5 eliminated · 1 selected
Hoshi Shinjuku Residences
★ 4.81,284 reviews 4-star Shinjuku, Tokyo Free wifi
Guest information required by hotel
First name
Kenji
Last name
Tanaka
Date of birth
1989-03-14
Nationality
Japan
Passport details sensitive
Passport number
{user.passport.number}
Expiry date
{user.passport.expiry}
Payment sensitive
Card number
{user.default_card.number}
Expiry
{user.default_card.expiry}
CVV
{user.default_card.cvv}
Cardholder
{user.default_card.name}
!
The agent never fetches these values. Sensitive fields are left as references. Real values live in Enterprise Private Storage and are resolved later, inside the enclave.
The agent never holds a credential it could lose.
Instead of resolving sensitive values, the agent assembles a structured execution request. Placeholders point to keys in Enterprise Private Storage. The request is sent to T3 Network, where resolution and execution happen inside a hardware-attested enclave.
◆
What the agent does carry: The Smart VC (proving authorisation), the booking parameters (hotel, dates, room), and references (placeholders) to sensitive values.
request transmitted to T3 Network →
execution_request.json
// Smart VC attached as proof of authorisation "vc": "eyJhbGciOiJFZERTQS...", "vc_subject": "did:t3:agent:travelops-001", // Action and parameters "action": "travel.hotel.book", "target": "travelhub.example/api/v2", "params": { "hotel_id": "hoshi-shinjuku-residences", "room_type": "premium_king_ns", "check_in": "2026-06-20", "check_out": "2026-06-24", "guest_name": "Kenji Tanaka", "passport": { "number": "{user.passport.number}", "expiry": "{user.passport.expiry}" }, "payment": { "method": "card", "card": "{user.default_card}", "amount": 75600, "currency": "usd" } }
return

A receipt. Nothing more.

The agent's context window receives a payment id, a booking reference, and a hash linking to the audit entry. No card number. No passport. No PII.

see receipt in the agent panel

←
concurrent

Confirmation reaches the user, not the agent.

In parallel, the booking platform emails confirmation to the registered user address. The agent had no email access. The user has the full record.

✓

Task complete.

From the user's perspective, the agent did its job within its authorisation. A booking exists. Sensitive data never entered the agent's context.

What the agent did

  • Searched hotels in Shinjuku
  • Applied VC constraints (4★, USD 200, non-smoking)
  • Selected highest-rated qualifying option
  • Built execution request with placeholders
  • Received receipt object

What the agent never saw

  • Passport number or expiry
  • Credit card number, CVV, or expiry
  • Payment authorisation token
  • User's email address
  • Cleartext booking confirmation

next: how did that actually work? →

behind the scenes

Inside T3 Network.

Same flow, different vantage point. Here is what happened inside the TEE during the execution request.

✓

The full picture.

Enterprise Claw turns "an agent doing something" into "an agent doing something you can prove, constrain, and audit". Three roles, one trust boundary.

What the agent did

  • Applied VC constraints
  • Selected hotel and room
  • Built execution request
  • Used placeholders, not values

What the agent never saw

  • Passport details
  • Card number, CVV
  • Payment authorisation
  • User's email

What T3N did inside the TEE

  • Verified Smart VC
  • Resolved placeholders from Private Storage
  • Charged payment via Agent Connect
  • Sealed audit entry on Merkle ledger
  • Returned receipt to agent
Inside T3 Network.
The request crosses into a hardware-attested TEE. Placeholders are resolved against Enterprise Private Storage. The transaction executes. An audit entry is sealed. None of this is visible from the agent runtime.
Remote attestation verified
Incoming request
action: "travel.hotel.book"
amount: 75600
card: {user.default_card}
passport: {user.passport.*}
⌬
Enterprise Private Storage
SG-residency · enforced at storage layer
TEE Node · WASM Runtime sealed
Payment API call
POST /v1/charges
status: "succeeded"
id: "pi_3OQzXR7..."
Merkle audit entry
block #1,284,701
0x9c4f1a02e8f33b7d9b4a6...e21a
Receipt to agent
only: payment_id, booking_ref, status, audit_root
T3N · TEE-attested confidential compute nothing on this screen is visible to the agent runtime