# Execution Plane
> **Coming Soon**: Implementation details finalize upon official release.
***
This page describes toani Control's **Execution Plane** components, cryptographic building blocks, connector model, and audit implementation.
> **Platform-level shared security foundation** (TEE concepts, crypto primitives, DCAP, immudb): [toani.ai Platform Security Foundation](/about-toani/platform-security.md). For product overview, see [toani Control Product Overview](/toani-control/overview.md). For system architecture, see [toani Control System Architecture](/toani-control/how-it-works.md).
***
## TEE and Isolation: Dual Hardware Division
| Component | Technology | Purpose |
| --------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Key Manager** | Intel SGX (process Enclave) | L1–L3 derivation, AES-256-GCM decryption, minimize TCB |
| **Token Signer** | Same Enclave as Key Manager | Sign PASETO v4.local **Action Token**, avoid cross-Enclave credential passage |
| **Connector Sandbox** | AMD SEV-SNP plus QEMU/KVM plus gVisor | External network, Playwright/API clients; credentials only injected via **RA-TLS** |
| **Audit Writer** | Standard service process | Only receives **scrubbed/hashed** payload; integrity depends on immudb plus signature chain, not requiring Writer in TEE |
***
## Four-Layer Key Hierarchy (Implementation-Oriented)
**Operational discipline**: L3 **never persists**; after decryption, buffer is immediately **libsodium `sodium_memzero`'d**.
***
## PASETO v4.local Action Token
* **Why not JWT**: avoids historical algorithm confusion issues; v4.local uses **XChaCha20-Poly1305** AEAD.
* **Properties (design)**:
* **Short TTL** (e.g., 15 minutes)
* **Single-use**: `jti` in Redis with `SET NX` plus TTL; consumed once, then invalid
* **Binding**: `policy_id`, `policy_version`, `action`, `params_hash`, risk Tier, HITL confirmation time and proof reference, `tee_mrenclave`, etc.
* **Encryption**: protected by symmetric key **derived from L1**, verifiable/decryptable only by **same MRENCLAVE** Issuer Enclave (keying specifics per implementation).
**Example payload concept** (field names per implementation):
```json
{
"jti": "uuid-v4",
"iss": "toani-control-tee-enclave",
"sub": "tenant_id:agent_id:user_id",
"exp": "2026-03-11T10:15:00Z",
"policy_id": "pol_wealth_mgmt_v2",
"policy_version": 2,
"action": "buy_stock",
"params_hash": "sha256:...",
"hitl_confirmed": true,
"risk_tier": 2,
"tee_mrenclave": "0x..."
}
```
***
## Connector Architecture
| Type | Target | Security Model Summary |
| ---------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------ |
| **Direct API** | REST/GraphQL etc. | Isolated process, brief HTTP client; API Key injected by TEE; response zeroed after |
| **OAuth Exchange** | OAuth2 service | Refresh token stored in Vault; **Access token swapped only in TEE**, single-use, not persisted |
| **Browser Automation** | Legacy Web | Playwright in gVisor; credentials entered into forms; policy can restrict screenshots, etc. |
| **Form Submission** | Single-direction form POST | POST assembled in TEE; no browser state retained |
| **Webhook / Callback** | Async, polling, callback | Long-lived credentials do not enter Agent; callback signature verification in TEE or trusted component |
### Connector Mandatory Security Configuration (Design Baseline)
```
Runtime: gVisor (runsc)
Network: egress whitelist per Policy target domains
Filesystem: root read-only; /tmp ephemeral
User: non-root (e.g., uid 65534)
Capabilities: all dropped
Seccomp: custom whitelist (design target: minimal syscalls)
Memory: limit (e.g., 512MB) plus memzero
Container life: one new container per execution, no cross-request reuse
Logging: filtered/scrubbed before persisting to disk
```
***
## Audit Layer (immudb)
**immudb selection rationale, Merkle structure, hash chain, and signature principles** appear in [Platform Security Foundation: Section 5](/about-toani/platform-security.md#immudb-audit-foundations). Below are **toani Control Execution Plane** field and export model specifics.
* **Storage**: immudb v1.9+, **no DELETE**; Merkle structure supports **inclusion proof**.
* **Record principles**: `params` stored as **hash only**; `user_id` can be **salted daily** to reduce linkage risk; includes `execution_receipt`, `tee_mrenclave`, HITL proof reference, `chain_signature`, etc.
* **Compliance export**: can generate **proof bundle** (Merkle root, path, TEE attestation report fragments, record list, verification guidance), for third-party **offline mathematical verification**.
### On-Chain Anchoring (if enabled)
Periodically publish Merkle root to on-chain state contract for **external timestamp and non-repudiation** (exact period and chain per implementation).
***
## Cryptographic Primitives and Protocol Selection
Crypto selections **shared with toani Vault** appear in [Platform Security Foundation: Section 3](/about-toani/platform-security.md#cryptographic-primitives-and-protocol-selection-cross-platform). The table below covers **Execution Plane / control plane implementation** additions and finalized selections (design):
| Category | Selection |
| ---------------------------------------------- | --------------------------------------------------- |
| AEAD (Action Token payload) | XChaCha20-Poly1305 (PASETO v4.local) |
| Memory zeroing | libsodium `sodium_memzero()` |
| Token revocation / single-use | Redis 7+ |
| Transport (execution chain / management plane) | mTLS 1.3 |
| Enclave development | Open Enclave SDK (design) |
| Remote attestation | Intel DCAP (consistent with platform documentation) |
| API framework (management service) | Fastify plus TypeScript |
| Management UI | Next.js 15 plus shadcn/ui |
***
## Implementation Differences from toani Vault
toani Vault and toani Control have design differences in TEE topology, key hierarchy, and sandbox approach; both honor the "plaintext never exits Agent, auditable, verifiable" product commitment. Details in [toani.ai Platform Security Foundation: Section 6](/about-toani/platform-security.md#three-product-security-model-comparison).
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.toani.ai/toani-control/execution-plane.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.