How Cabal executes trades on your behalf without ever exposing your private keys to the AI.

The Security Model

Cabal trades real money. That means the security model is not a nice-to-have -- it is the foundation everything else rests on. This guide explains how Cabal keeps your keys, credentials, and funds isolated from the AI agent, and why that isolation holds even if the AI misbehaves.

The problem with other trading bots

Most trading bots ask you to hand over the keys to the kingdom. Exchange API keys with withdrawal permissions. Wallet seed phrases pasted into a .env file. Private keys stored alongside bot code on a VPS you hope nobody compromises.

The implicit deal is: trust the bot, and hope nothing goes wrong.

If the bot gets hacked, your keys are compromised. If the hosting provider has a breach, your keys are compromised. If the AI hallucinates a malformed API call or gets tricked by a prompt injection, there is no backstop between the model's output and your wallet. The bot has the same access you do, and it exercises that access with whatever judgment the code (or the model) happens to produce.

This is the standard model. Cabal does not use it.

How Cabal keeps your keys separate

Cabal's architecture has a hard boundary between the AI agent and everything that touches your money.

Your agent runs in an isolated environment -- think of it as a sealed room. Inside the room, the agent can reason, research, read data, and propose actions. It has tools for analysis and planning. But the room has no door. The agent has no outbound network access. It cannot reach the internet, your wallet, your API keys, or any external service directly.

The agent communicates through a controlled channel -- like a phone mounted on the wall of the room. It can request market data, propose trades, or ask for tool results. Every request goes to the parent system, which sits outside the room and decides what to allow. The parent system owns your credentials, enforces your risk limits, and controls all communication with blockchains and external services.

This is not a permissions model where the agent has access but is told not to use it. The agent literally cannot make HTTP requests. The network is not available. Every capability the agent needs flows through the parent system, which mediates every interaction.

How a trade actually happens

Here is what happens when your agent executes a trade, step by step:

The agent decides to trade. Based on a signal, your standing instructions, or its own analysis, the agent decides to buy 2 SOL of a token.
The agent calls the trade tool. This sends a structured request to the parent system -- not to the blockchain. The agent describes what it wants to do, but it does not construct or sign any transaction.
The parent system retrieves a quote. The parent system contacts the trading venue (Jupiter for Solana, LI.FI for EVM chains, Hyperliquid for perps) and gets a quote for the requested trade.
The parent system runs your guardrail checks. Price impact, trade size, daily volume cap, market liquidity, market age -- every guardrail you have configured is evaluated against the quote. This happens entirely outside the agent sandbox.
If all checks pass, the parent system builds and signs the transaction. Your custodial wallet's signing key is used here. The key lives in the parent system. It has never been inside the agent's environment.
The parent system submits the signed transaction to the chain. The parent system handles the RPC call, monitors confirmation, and records the result.
The result flows back to the agent as a tool response. The agent receives confirmation of success or failure, along with the actual amounts. It never sees the raw transaction, the signing key, or the network response.

At no point does the agent have access to signing material. The private key never leaves the parent layer. Even if you could somehow convince the agent to try to exfiltrate credentials, there are no credentials in its environment to exfiltrate.

Guardrails are deterministic checks the agent cannot bypass

This is not prompt engineering. Your risk limits are not "instructions" the AI interprets. They are simple, deterministic comparisons -- is this number above your limit? -- that run outside the agent's environment before any transaction is signed.

The agent cannot see these checks, modify them, or request an exception. When your agent wants to trade, it sends a request. The parent system loads your guardrail settings from the database, runs every check, and either signs the transaction or rejects it. The agent gets back a result. That is its only path to execution.

This matters because AI models are probabilistic -- they can be creative, unpredictable, or wrong. A guardrail that exists as a prompt instruction is only as reliable as the model's willingness to follow it. A guardrail that exists as a hard comparison in a separate environment, running before the transaction is signed, holds regardless of what the model does or tries to do.

Control profiles as a trust gradient

Cabal does not force you into an all-or-nothing choice. You control how much autonomy your agent has through three levels:

Suggest only -- the agent can research, analyze, and propose trades. Every execution requires your explicit approval. Nothing happens without your tap. This is the right starting point for building confidence in how the agent thinks before letting it act.

Autonomous guardrailed -- the agent can execute trades on its own, but only within the limits you set. Those limits are enforced server-side, not by the AI. If a trade violates a guardrail, it is blocked -- no override, no exceptions. This is the production mode for most users.

Autonomous unrestricted -- maximum delegation. Guardrails still apply, but with fewer implicit constraints on background execution. Intended for advanced users with well-tuned guardrail configurations.

You choose the level. You can change it at any time from your agent's settings. You can revoke autonomous access instantly, and the change takes effect on the next action the agent attempts.

Credential isolation

The isolation extends beyond wallet keys. Every credential your agent needs is kept outside the sandbox.

Model provider keys -- API keys for Claude, OpenAI, and other inference providers are stored encrypted and resolved server-side. When the agent needs to run inference, the parent system handles authentication. The sandbox never sees the raw API key.

Wallet credentials -- managed through Privy's custodial infrastructure. Your wallet's signing keys exist in a secure environment that the sandbox interacts with only through structured bindings. The agent requests trades; the parent system handles signing. No key material enters the sandbox.

Data provider keys -- services like Helius and DefiLlama require API keys for market data, on-chain lookups, and indexing. You can provide workspace API keys that let your agent use your data subscriptions. These keys are resolved server-side, and the sandbox accesses data through scoped channels without ever seeing the raw key value.

Webhook secrets -- used for signal delivery from services like Helius and Alchemy. These secrets authenticate incoming webhooks and are handled entirely server-side. The agent receives processed signal data, not raw webhook payloads.

What this means for you

The architecture has practical implications beyond security:

You can try different AI models without worrying about key exposure. Switching from Claude to GPT-4 does not change who has access to your wallet. The model runs inside the sandbox; your keys stay outside it. Swapping models is a configuration change, not a security decision.
You can enable autonomous trading knowing the risk limits are deterministic. Guardrails are not suggestions the AI might ignore. They are hard comparisons that block non-compliant trades before signing. If you set a 5 SOL max trade size, that limit holds -- it is a number compared against a number, not a prompt the model interprets.
You can track wallets and research on-chain data without ever giving anyone your private key. Research tools, market data, and signal tracking all operate through the same mediated channel. Your agent gets the data it needs to analyze opportunities. It never gets access to your signing keys in the process.
The security model does not degrade as the product grows. When Cabal adds new AI capabilities, tools, or integrations, they operate within the same isolation boundary. New tools are bindings mediated by the parent system, not new holes in the sandbox. The sealed room stays sealed.