Published security architecture

How FortFi is built

A public view of our stack: where keys live, where policy runs, and what FortFi can and cannot do. This is the same model described in our security overview — distilled for builders, auditors, and anyone evaluating FortFi for real money.

System stack & trust boundaries

FortFi is a control plane, not a custodian. Your signing keys are generated and used inside Turnkey's TEE infrastructure. FortFi servers authenticate you, evaluate policy, and request signatures — they never hold raw private keys.

FortFi orchestrates policy and approval; Turnkey enclaves hold and use signing keys.

ActionIntent pipeline

Every money-moving action — send, swap, bridge — is an ActionIntent. Nothing executes until policy passes, fees are disclosed, and you (or your co-signers) explicitly approve. Denied intents never reach Turnkey.

Policy before signature; audit log written with every settled action.

Human vs agent paths

FortFi Assist drafts intents — it never signs. Autonomous agents use scoped API keys and operate inside allowlists, spend caps, and co-signer thresholds you set. Agents cannot loosen policy without a fresh signature from your funding wallet.

Both paths converge on the same policy-gated execution layer.

What runs where

  • Browser / mobile

    Passkey authentication, intent review UI, and Turnkey export iframe. No seed phrases stored locally by default.

  • FortFi API

    Authentication, authorization, policy engine, ActionIntent lifecycle, agent MCP, and immutable audit writes.

  • Turnkey TEE

    Key generation, storage, and signing inside secure enclaves. FortFi requests signatures; it never receives raw key material.

  • On-chain (Base, Ethereum, Solana, BNB Chain, and Hyperliquid, and more)

    Settled assets live on public chains. FortFi adds governance and controls; it does not take possession of your funds.

Hard boundaries (public commitments)

  • No private keys on FortFi servers

    Wallet provider abstraction in packages/wallet; no direct key material in app or API layers.

  • AI creates intents only

    Assist and agent tools propose actions. Execution requires policy pass plus human or co-signer approval.

  • Allowlist enforced server-side

    Recipients must be trusted before payout. UI checks are not sufficient — policy engine blocks unknown addresses.

  • Financial records are append-only

    Ledger and audit entries are written in the same transaction as state changes. No delete or update on audit tables.

  • Agent keys are scoped and revocable

    API keys are hashed at rest, shown once at creation, and tied to explicit permission scopes.