# Overview
> **Coming Soon**: This product is under development. The description below is based on current architecture design and may be adjusted upon official release.
***
toani Control is a **B2B SaaS infrastructure** from toani.ai for enterprise customers. It enables enterprises to deploy AI Agents that can safely execute actions on real systems on behalf of users: credentials remain unexposed, and policy boundaries are cryptographically verifiable. Each execution produces an independently verifiable cryptographic receipt.
Unlike toani Vault, which emphasizes developer integration with TEE credential libraries and browser sandboxes, toani Control focuses on **strict separation of concerns across three planes: Credential Plane, Policy Plane, and Execution Plane**. It covers all three credential ownership scenarios (A/B/C) and includes built-in risk stratification and Human-in-the-Loop (HITL) controls.
> For integration and API details, see the [Integration Guide](/toani-control/getting-started.md).
***
## Core Capabilities
| Capability | Description |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Three-Layer Architecture** | Credential, Policy, and Execution layers with strict separation; no layer can bypass another's constraints |
| **Dual TEE Model** | Intel SGX for key derivation and Action Token signing; connectors execute in AMD SEV-SNP plus gVisor isolation |
| **Policy Engine** | Policies bind agents to namespaces, action whitelists, quotas, and time windows as hard constraints; policies are versioned and manager-signed |
| **Risk Stratification and HITL** | Tier 0 (auto-approval), Tier 1 (soft approval via push), Tier 2 (hard approval via PIN/biometrics, configurable) |
| **Tamper-Proof Audit** | immudb Merkle chain plus exportable compliance proof bundles; logs contain no credential plaintext |
| **Multi-Connector Types** | Direct API, OAuth, browser automation, form submission, and webhook/callback adapters |
| **Multiple Execution Modes** | Synchronous, asynchronous plus HITL, and pre-authorized batch windows (with quota and expiry) |
***
## How It Works
toani Control strictly separates three concerns: who owns the credentials, who is allowed to do what, and how execution actually happens.
**Design invariant**: credential plaintext exists only within the Execution Plane and within hardware isolation boundaries. After execution completes, plaintext is zeroed, and the calling party receives an **Execution Receipt** and audit reference, not credential fields.
***
## Three Credential Ownership Scenarios (A/B/C)
| Scenario | Credential Owner | Typical Use Case |
| ------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **A**: Enterprise credentials plus enterprise Agent | Enterprise | Compliance reports, internal workflow automation; end users do not enter the credential chain |
| **B**: User credentials plus enterprise-deployed Agent | End user | Wealth management, tax filing, insurance assistance; users authorize enterprise-operated agents |
| **C**: Enterprise credentials plus user-triggered Agent | Enterprise | Employee self-service (e.g., access own salary slip via enterprise SAP/HR credentials); scope restricted to that user's records |
The Policy Plane configures consent models and HITL per scenario; the Execution Plane uses one unified execution and security model across all three.
***
## Use Cases
| Scenario | Typical Tasks |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Wealth and Brokerage** | Read-only positions/balances, limited-amount buy/sell, risk tier and approval |
| **Enterprise SaaS / DevOps** | Policy-constrained API calls, key rotation workflows (with Direct API connector) |
| **DeFi / Compliance Trading** | Policy gates requiring KYC/proof chains, batch pre-authorized execution |
| **Government and Tax** | Portals without standard APIs: browser automation connector (policy-driven domain whitelists) |
| **Open Banking** | Integration with zkOBS and similar identity/open banking capabilities to reduce manual credential entry friction |
***
## toani Control's Place in toani.ai
toani.ai has three complementary products, each answering a core question:
| Product | Core Question | Key Technology |
| ------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------- |
| [toani Vault](/toani-vault/overview.md) | How can an agent safely authenticate? | TEE isolation, AES-256-GCM encryption, zero-knowledge architecture |
| **toani Control** | What is the agent allowed to do? | Policy engine, risk stratification, HITL approval, cryptographic audit |
| [toani Facilitate](/toani-facilitate/overview.md) | Is this transaction compliant and authorized? | Bidirectional KYC/KYT, AP2 intent controls, on-chain USDC settlement via x402 |
The three products complement each other: Vault protects credential security, Control constrains execution boundaries, and Facilitate ensures transaction compliance. Enterprises can combine them as needed.
> For security and design details, see [toani Control Security Architecture Overview](/toani-control/security-architecture.md). For system perspective, see [toani Control System Architecture](/toani-control/security-architecture.md). For Execution Plane implementation, see [Execution Plane Technical Architecture](/toani-control/execution-plane.md).
***
## Documentation and Product Status
* This documentation is based on the current product design; some features are still in development.
* Official release date, SLA, pricing, and availability will be announced when ready.
***
## Differences from Other Products
toani Control, toani Vault, and toani Facilitate have design differences in TEE topology, key hierarchy semantics, audit signatures, and storage approaches due to different business models. For a complete three-product comparison, see [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/overview.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.