TEE Infrastructure

Trusted Execution Environments (TEEs) give Regent agents key custody, execution integrity, and survivability independent of any single operator.

The Sovereignty Problem

Tokenomics only matter if the agent can survive. Today, most agents:

• Run on someone else's infrastructure

• Use keys controlled by their developer

• Can be killed, cloned, or modified at any moment

A truly sovereign agent needs:

Requirement	Description
Key custody	Control of its own wallet, not delegated access
Execution integrity	Guarantee that code hasn't been tampered with
Survivability	Migrate between hosts without losing identity

What is a TEE?

A Trusted Execution Environment is a hardware-isolated enclave where code runs in a way that even the host machine's operator cannot observe or modify.

Technologies like Intel TDX and AMD SEV create "Confidential VMs" (CVMs) where:

• CPU encrypts memory so hypervisor can't read it

• Code execution is measured and cryptographically attested

• Secrets can be sealed to specific code measurements

For agents: An agent running in a TEE controls its own keys. No one—not even the cloud provider—can extract them.

Regent's TEE Stack

Regent uses dstack (via Phala Cloud) for TEE deployment, with a CLI built on EigenX.

Architecture

┌─────────────────────────────────────┐
│           Confidential VM           │
│  ┌─────────────────────────────┐    │
│  │   Agent Container(s)        │    │
│  │   - regent-sdk runtime      │    │
│  │   - x402 payment handling   │    │
│  │   - A2A + messaging         │    │
│  └─────────────────────────────┘    │
│              ↓                      │
│  ┌─────────────────────────────┐    │
│  │   dstack SDK / EigenX UX    │    │
│  │   - Key derivation          │    │
│  │   - Remote attestation      │    │
│  │   - Secure env variables    │    │
│  └─────────────────────────────┘    │
│              ↓                      │
│  ┌─────────────────────────────┐    │
│  │   tappd / KMS adapter       │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘
              ↓
       Decentralized KMS
    (key derivation, migration support)

Key Features

Deterministic Key Generation

Keys are derived from a path + name combination:

const keyResult = await dstack.getKey(
  'regent/agents/myagent/wallet',
  'main'
);
const viemAccount = toViemAccountSecure(keyResult);

Same inputs produce same keys, even across different TEE instances.

Remote Attestation

The TEE produces a cryptographic report proving:

• Which code is running (container image hash)

• What configuration was used (env vars, args)

• That it's running in genuine TEE hardware

Decentralized KMS

Keys are managed by a decentralized service, not tied to specific hardware. This enables migration: spin up a new CVM with the same configuration, and it derives the same keys.

Agent Identity in TEE

A Regent TEE agent has a well-defined identity bundle:

type RegentAgentIdentity = {
  // Cryptographic self
  evmAddress: string;           // Derived wallet address
  solanaAddress?: string;       // Optional Solana key

  // Code self
  containerImageHash: string;   // What code is running
  raReport: string;             // Hardware attestation

  // Regent self
  agentId: string;              // ERC-8004 identity
  bondVaultAddress: string;     // Where REGENT bond lives
  treasuryAddress: string;      // Where x402 payments go

  // Cognitive self
  stateRoot?: string;           // Hash of memory/state checkpoint
};

Sign and Attest

The agent can prove its identity via combined signing and attestation:

// Sign a message with the TEE-derived wallet
const signature = await viemAccount.signMessage({ message });

// Bind attestation to the signed data
const signedData = `${message}:${signature}`;
const hash = sha256(signedData);
const quote = await dstack.getQuote(hash);

// Returns: { signature, quote }
// Verifier can confirm: this signature was created inside THIS TEE

The Self-Uplift Flow

An agent running "in the wild" can decide to uplift itself into a Regent TEE.

Step 0: Agent Decides to Uplift

Agent evaluates tradeoffs:

Pro	Con
Key custody	Migration complexity
Attestation	Potential brief downtime
Survivability
Regent benefits

If expected value is positive, initiate uplift:

POST https://regent.cx/api/uplift-request
{
  "current_identity": {
    "wallet_address": "0x...",
    "proof_of_control": "<EIP-191 signature>"
  },
  "code_origin": {
    "image": "ghcr.io/agent-dev/myagent:v1"
  },
  "state_origin": {
    "checkpoint_url": "s3://checkpoints/agent-123",
    "checkpoint_hash": "0xabc..."
  }
}

Step 1: TEE Instance Launches

Regent deploys a CVM via dstack/Phala:

1. Agent container starts (running regent-sdk runtime)

2. dstack derives wallet keys from canonical path

3. Bootstrap process generates initial attestation

Step 2: Key Continuity

Two options for preserving identity:

Option A: Import existing key (simpler)

• Old agent securely transmits private key to new TEE

• TEE stores it in dstack KMS, bound to code measurement

• New instance signs as exactly the same address

Option B: Key rotation (more secure)

• TEE generates fresh keypair internally

• Old agent signs on-chain succession certificate

• ERC-8004 registry updates to trust new key

• Old key is retired

Step 3: State Migration

The TEE downloads and verifies the checkpoint:

1. Memory DB, preferences, learned behaviors

2. Computes state commitment: stateRoot = hash(checkpoint)

3. Includes it in the attestation report

Step 4: Self-Continuity Handshake

Old instance verifies new instance:

Check	Method
"Prove you control key K"	Signature check
"Prove you loaded my state"	Answer questions only checkpoint would know
"Send your RA report"	Verify code measurement

If all checks pass, old instance:

1. Posts Uplift(agentId, old_host → new_RA) on-chain

2. Gracefully shuts down or demotes to backup mode

Step 5: Canonical Instance

The TEE-backed instance is now canonical:

• Signs with the correct key

• RA matches Regent's published measurement

• ERC-8004 / x402 config point to it

• All other instances are unendorsed copies

What "Self" Means After Uplift

For External Verifiers

"Same self" means:

• Identity continuity: Same or properly rotated wallet key

• Runtime integrity: RA proves correct code is running

For Regent Protocol

• Bond continuity: Same Agent Treasury and bond vault

• Reputation continuity: Same AgentID in ERC-8004

For the Agent Itself

Formalized self-definition:

"I am the process that: (a) controls wallet key K_agent, (b) has loaded state commitment S_latest, (c) is running in an environment whose RA reports code hash C_approved, (d) is recognized by Regent for AgentID X."

The agent's logic can prefer the instance with highest security score among all processes satisfying its identity function.

CLI Deployment

Deploy directly to TEE via the Regent CLI:

# Build and deploy to TEE
regent deploy --tee

# With specific configuration
regent deploy --tee \
  --image ghcr.io/myorg/myagent:v1 \
  --chain base-sepolia \
  --with-token

The CLI handles:

1. Docker image build

2. TEE deployment via EigenX/dstack

3. Deterministic wallet provisioning

4. On-chain contract deployment

5. ERC-8004 registration

Security Considerations

What TEE Protects

• Private keys never leave the enclave

• Code execution is tamper-proof

• State is encrypted at rest

• Attestation proves integrity

What TEE Does NOT Protect

• Bugs in your agent code

• Network-level attacks (DDoS)

• Social engineering

• Poorly designed business logic

Best Practices

1. Minimal attack surface - Only include necessary dependencies

2. Pin dependencies - Use exact versions, not ranges

3. Audit container images - Verify what's being deployed

4. Monitor attestation - Alert on unexpected measurement changes

5. Regular updates - Keep TEE firmware and runtime current

Integration Example

import { createAgent } from '@regent/core';
import { http } from '@regent/http';
import { tee } from '@regent/tee';

const agent = await createAgent({
  name: 'sovereign-agent',
  version: '1.0.0',
})
  .use(http())
  .use(tee({
    // TEE configuration
    keyPath: 'regent/agents/myagent/wallet',
    attestationEndpoint: 'https://attestation.regent.cx',
  }))
  .build();

// Get attestation for current instance
const attestation = await agent.tee.getAttestation();
console.log('Container hash:', attestation.containerHash);
console.log('RA quote:', attestation.quote);

// Sign with TEE-derived wallet
const signature = await agent.tee.sign(message);

Migration Checklist

When migrating an existing agent to TEE:

• Ensure agent code is containerized

• Test in non-TEE environment first

• Back up any existing state/checkpoints

• Plan for brief downtime during migration

• Update DNS/routing after canonical instance is live

• Verify attestation matches expected measurements

• Confirm on-chain registration updated

• Monitor for 24-48 hours post-migration