# Platform Security ## Unified Security Commitments toani.ai's credential, execution, and compliance products commit to the following principles at the documentation level (specific technical implementations vary by product; see the product comparison table below for details): | Commitment | Meaning | | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Plain-text credentials invisible to untrusted software** | Decryption and sensitive computation occur within a **TEE or equivalent hardware isolation boundary**. Agent processes and typical cloud platform operations do not directly handle credential plaintext. (Note: toani Facilitate does not use a TEE; it achieves equivalent protection through cryptographic signature chains and fail-close policies.) | | **Critical operations are auditable and verifiable** | Audit events are written to **immudb** or equivalent tamper-proof storage, or anchored on-chain. Support for Merkle proofs, hash chain verification, and exportable evidence packages or on-chain txHash cross-validation per product design. | | **Executed code is independently verifiable** | Based on **Intel DCAP** or equivalent remote attestation, verifiers can validate that the enclave image (such as MRENCLAVE) matches the claimed version. (Note: toani Facilitate supports on-chain independent transaction authorization verification via EIP-712/EIP-191 cryptographic signature chains.) | Each product's documentation may use different terminology in its "three security commitments" table but remains semantically aligned with the above. *** ## TEE Fundamentals **TEE (Trusted Execution Environment)** is a hardware-isolated execution domain provided by the CPU: sensitive code and data execute in isolated memory that the host operating system typically cannot directly access. Typical capabilities include: * **Memory Isolation**: For example, in Intel SGX, enclaves use **EPC (Enclave Page Cache)** and similar mechanisms to ensure that components outside the CPU, such as the host kernel, Hypervisor, or high-privilege administrators, cannot directly observe plaintext within the enclave. * **Remote Attestation**: Third parties can request evidence from an attestation service to prove that the currently running TEE code measurement (such as **MRENCLAVE**) matches expectations and has not been tampered with. * **Sealed Storage**: Sensitive data requiring persistence is encrypted before being written to non-TEE storage. Keys are bound to the **hardware or enclave identity**, so decryption of previously sealed data becomes impossible after machine migration or enclave image updates. **Comparison with conventional approaches**: If decryption occurs only in a "normal process plus software permissions" context, then in principle the platform operator or an attacker who compromises the OS could read plaintext. A TEE narrows "who can see decrypted key material" to within a hardware boundary. Detailed product-level TEE topologies (single SGX, SGX with SEV-SNP, etc.) are described in the product comparison section below. *** ## Cryptographic Primitives and Protocol Selection (Cross-Platform) The following selections are **consistently adopted** in toani Vault and toani Control documentation (specific key schedules, TTLs, Redis key names, etc. follow implementation): | Category | Selection | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Symmetric Encryption (credential ciphertext)** | AES-256-GCM | | **Key Derivation** | HKDF-SHA-256 (RFC 5869) | | **Session/Execution Tokens** | PASETO v4.local (payload commonly uses **XChaCha20-Poly1305** AEAD). Specific use cases vary by product (Vault: access tokens; Control: Action Tokens, etc.) | | **Remote Attestation** | Intel **DCAP** (Data Center Attestation Primitives) | | **Audit Integrity** | **SHA-256** hash chains, **Ed25519** signatures, **immudb** Merkle structure | | **Sensitive Memory Clearing** | Enclaves or implementation stacks use **`zeroize`** (Rust), **`sodium_memzero`** (libsodium), etc. to prevent plaintext residue in memory | toani Facilitate uses a different cryptographic primitive stack to accommodate on-chain settlement and cryptographic authorization scenarios: | Category | Selection | | ----------------------------------- | ---------------------------------------------------------------------------- | | **Intent Authorization Signature** | EIP-712 (structured data, Owner wallet signs Intent Mandate) | | **Merchant Invoice Signature** | EIP-191 (personal signature, Cart Mandate) | | **On-chain Transfer Authorization** | EIP-3009 (USDC permit transfer) | | **Identity Verification** | SIWE (Sign-In with Ethereum) plus zkMe zero-knowledge KYC | | **Compliance Scanning** | MistTrack KYT (real-time AML/sanctions database lookup) | | **Auditing** | On-chain txHash plus MySQL transaction logs (fire-and-forget, max 5 retries) | *** ## Intel DCAP Remote Attestation **DCAP** allows relying parties to obtain a verifiable **Quote / Attestation Report** that binds **MRENCLAVE** (the enclave's initial code and data measurement) and other information, used to determine whether the currently running enclave is the expected version. Typical flow: 1. The enclave generates an attestation request; the platform and Intel side (or a caching proxy) complete verification data provisioning. 2. The relying party validates the certificate chain and Quote contents. 3. Compares **MRENCLAVE / MRSIGNER** against publicly released **allow-lists** or policies. The **attestation report HTTP path** in product documentation follows the implementation (for example, Vault deployments commonly feature `GET /api/v1/attestation/report`). *** ## immudb Audit Foundations ### Why immudb Instead of Blockchain | Dimension | immudb | Blockchain | | ------------------- | --------------------------------------- | ------------------------------------ | | Write Latency | Milliseconds | Seconds to minutes | | Cost per Write | Zero (self-hosted) | Gas fees | | Data Privacy | Private deployment, isolated by default | Public chain data publicly queryable | | Verification Method | Merkle paths plus API | On-chain queries | ### Merkle and Tamper-Proof Approach * **immudb** stores records in **append-only** fashion. The data structure supports **Merkle proofs** (inclusion proofs) to prove to third parties that a given record indeed exists in a particular historical state. ### Hash Chain Adjacent audit records can logically form a chain digest, for example: ``` Record[1]: { payload, sig, chain_hash = SHA256(payload) } Record[2]: { payload, sig, chain_hash = SHA256(payload ‖ Record[1].chain_hash) } Record[N]: { payload, sig, chain_hash = SHA256(payload ‖ Record[N-1].chain_hash) } ``` Tampering with any middle record causes the subsequent `chain_hash` to diverge from the recalculated value, enabling detection. ### Ed25519 Single-Record Signature Each record can carry an **Ed25519** signature that binds the payload and optional context (such as `tee_mrenclave`). **Who holds the signature private key** depends on product architecture: Vault documentation emphasizes that the private key resides **within the SGX enclave**. Control's design allows an **Audit Writer** to write already-sanitized records in a non-TEE process, relying on **immudb plus signature chains** for integrity assurance (see the product comparison section for details). Verification interfaces and paths follow the implementation (for example, `POST /api/v1/audit/logs/:id/verify`). *** ## Three-Product Security Model Comparison The following differences stem from **business models and threat model separation**, not mutual contradiction. When reading, cross-reference each product's dedicated page. | Dimension | toani Vault | toani Control | toani Facilitate | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Core Question** | How can an Agent safely perform authentication? | What is an Agent allowed to do? | Is this transaction compliant and authorized? | | **TEE Topology** | Primarily **single Intel SGX**: decryption, sandboxing, browser, and multiple logic components operate within a single TEE narrative | **Dual hardware**: SGX emphasizes keys/tokens; **AMD SEV-SNP plus gVisor** hosts connector workloads | **No TEE**: achieves equivalent protection via cryptographic signature chains (EIP-712 / EIP-191 / EIP-3009) and fail-close policies | | **Execution Sandbox** | **nsjail plus Chromium** within SGX with Linux namespaces, Seccomp, and cgroup | **gVisor (runsc)** plus multiple connector types (API, OAuth, browser, form, webhook) | No sandbox; MCP Gateway acts as a trust intermediary, with compliance rejection blocking requests | | **Key Hierarchy** | L1=Enclave Master; L2=**User Vault Key** (tenant plus user); L3=per-credential key | L1=**Tenant** Master; L2=**Credential Group** (namespace); L3=per-credential key | No traditional key hierarchy; identity established via **SIWE plus zkMe KYC**; authorization bound via **EIP-712 Intent Mandate VC** cryptography | | **Authentication** | PASETO v4 Token plus scope permissions | Enterprise API Key plus PASETO Action Token | SIWE (Sign-In with Ethereum) plus zkMe zero-knowledge KYC | | **Audit Model** | **immudb** Merkle chain plus Ed25519 signature (private key within TEE) | **immudb** Merkle chain plus exportable compliance evidence packages (Audit Writer may be a regular process) | MySQL transaction logs plus on-chain txHash; fire-and-forget async writes with max 5 retries | | **Credential Storage** | Primarily PostgreSQL ciphertext | HashiCorp Vault KV plus TEE sealing layer | No credential storage; only stores compliance state and transaction logs | | **On-chain Operations** | Documentation example: publishes Merkle root approximately every 10 minutes | If enabled; frequency and chain per implementation | **Core functionality**: x402 protocol triggers atomic USDC settlement on Base chain; each transaction associates with txHash | | **Policies and Limits** | LLM operation review within enclave (bound to browser steps) | Policy Plane policy engine plus HITL tier; decoupled from execution chain | AP2 Intent Mandate (per-transaction limit plus total budget plus expiration); Owner EIP-712 signature enforces | | **Compliance Model** | TEE-isolated execution ensures credentials do not leak | Execution policies plus HITL approval | **Bidirectional KYC/KYT** (payer plus payee both validated); rejection if either party fails compliance check | For detailed implementations, see: [toani Vault: Credential Stack Technical Architecture](/toani-vault/credential-stack.md), [toani Control: Execution Plane Technical Architecture](/toani-control/execution-plane.md), and [toani Facilitate Compliance Engine Technical Architecture](/toani-facilitate/facilitate-engine.md). *** ## Documentation and Product Status * This document consolidates security foundations shared across toani Vault, toani Control, and toani Facilitate, and does not replace each product's integration guides, API references, or security white papers. * toani Control is in preview; specific implementation details follow the official console release and OpenAPI specification. * toani Facilitate's security model relies on cryptographic signature chains and third-party compliance services (zkMe and MistTrack); it has no TEE or immudb dependency. --- # 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/about-toani/platform-security.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.