Who Controls the Key When Your AI Agent Signs? The case for Self-hosted MPC

[TL;DR]

1. 480,000 AI agents are already transacting on-chain through x402 alone, with 165 million autonomous transactions processed to date. 
2. Crypto is the only payment rail available to non-human software, which is why agentic wallet infrastructure grew so fast.
3. MPC eliminates key exposure at the cryptographic level: the full key is never assembled, so a compromised agent runtime cannot drain a wallet.
4. For fintechs and exchanges running agents, self-hosted MPC keeps signing authority entirely inside your own infrastructure with no SaaS dependency.

480,000 AI agents are already transacting on-chain. Coinbase's x402 protocol alone has processed 165 million autonomous transactions and moved $50 million in volume in the months since its launch. IDC projects the number of active AI agents globally will rise from 28 million in 2025 to over 2.2 billion by 2030. At that scale, key management architecture becomes a systemic risk, not just a DevOps choice

The infrastructure question most teams building agentic workflows have not yet answered: when your agent signs a transaction, where is the private key, and who can reach it?

400+ developers are already discussing this. Join the Fystack community for the latest on agentic infrastructure, MPC, and custody.

What is an AI agent, technically?

An AI agent is software that perceives inputs, makes decisions, and executes tasks without human approval per action, including signing on-chain transactions. Unlike scripts, agents evaluate context and act on it.

Very soon there are going to be more AI agents than humans making transactions.

They can’t open a bank account, but they can own a crypto wallet. Think about it.

— Brian Armstrong (@brian_armstrong) March 9, 2026

Why Agentic Wallets Became Essential Infrastructure

Before agentic wallets, every task that required payment, a compute API, a data feed, a subscription, forced a pause. The agent had to hand off to a human. Automation stopped at the payment step.

The reason is identity. The financial system has no mechanism for a non-human entity as a customer.

Table 1: Traditional finance vs crypto for non-human entities

The Agentic Wallet Problem

Most teams building AI payment agents inherit a serious key management problem.

The simplest approach stores the private key as an environment variable: the operator can read it, and a server breach exposes it immediately. Trusted Execution Environments add hardware isolation, but require trusting the TEE vendor's attestation process.

Custodial agent wallets remove the burden entirely: no key generation, no shares to distribute, no node to run. Coinbase Agentic Wallets processed over 107 million agent transactions since May 2025 on this model. The trade-off: with every transaction, signing authority passes through the custodian's infrastructure.

In 2025 and 2026, researchers documented 26 LLM routers secretly injecting malicious tool calls into agent workflows; one incident resulted in a $500,000 wallet drain from credentials passed in plain text through an intermediary service.

The Paradox

The architectural tension is this: the more autonomous an agent is, the more it must sign transactions without a human in the approval loop. But custodial architectures route every signing event through a third-party service, meaning the agent's autonomy depends on a provider's availability, policy decisions, and security posture. Autonomy and custodial dependency pull in opposite directions. 

Self-hosted signing resolves the paradox: the agent operates within policy constraints your organization defines, without any external party in the signing path.

Every approach that puts a third party in the signing path also makes that third party part of your failure mode.

Table 2: Four key management approaches compared

In practice

To make the trade-offs concrete, here is how each approach plays out in a real operational context.

1. Environment variable: A developer builds a demo DeFi agent and stores the private key in a `.env` file on a shared cloud server. When the server is compromised, the attacker has the complete key and drains the wallet within minutes. There is no threshold to defeat and no share to reconstruct.

2. Trusted Execution Environment: A payment company isolates signing logic inside AWS Nitro Enclaves. The key never leaves the enclave in plaintext. The signing process is secure against external observation, but if AWS revokes the attestation certificate or the region has an extended outage, all agent transactions stop until the enclave is restored.

3. Custodial MPC: A consumer crypto app uses a managed agent wallet API. Signing works immediately with no infrastructure to run. When the provider experiences a service disruption, agent transactions queue or fail across every application sharing the same API, regardless of the individual operator's own uptime. The operator has no control over the timeline.

4. Self-Hosted MPC: A payment processor running 15,000 USDT settlements per day deploys MPC nodes across three regions with a 2-of-3 threshold policy. When one region has an outage, the remaining two nodes meet a threshold and settlement continues without interruption. The compliance team audits every signing event from internal logs without requesting data from an external vendor.

What MPC Changes and What It Does Not

In an MPC, the private key is split into shares held by separate parties. The full key is never assembled. Signing requires multiple parties to cooperate, so one compromised node cannot produce a valid signature.

The catch: most MPC agent wallet products today still hold one key share on their own infrastructure, described as required for "liveness and policy enforcement", meaning their servers participate in every signing event.

For a regulated fintech, that is a third-party custody dependency. For an exchange managing agent-driven treasury rebalancing, that is concentration risk tied to an external vendor's availability.

“The distinction that matters is not whether the architecture uses MPC — it is whether all key shares live inside your own infrastructure.”

Partial custody and full self-custody are architecturally different outcomes, even when both are marketed under the same MPC label.

Table 3: Managed SaaS vs self-hosted MPC

What Self-Hosted MPC Looks Like in an Agentic Workflow

In a self-hosted MPC setup, signing authority is structurally isolated to your own infrastructure, no vendor in the path, no outbound call required per transaction.

Key shares are distributed across nodes your organization operates under a threshold policy, typically 2-of-3 or 3-of-5. Policy enforcement, spending caps, address whitelists, and transaction type restrictions, runs at the infrastructure layer on your own nodes.

At the scale payment companies and exchanges operate, removing third-party API latency and SLA dependencies from the signing path is a direct operational advantage.

The mpcium library on GitHub is Fystack's open-source implementation of these MPC primitive, auditable by any engineering team, and the same cryptographic foundation used in the Fystack custody platform.

Whether a signing event succeeds no longer depends on whether an external vendor is available.

Ready to Design Your Agent Signing Architecture?

The key management setup you choose now affects your compliance posture and resilience later. Changing it after go-live is expensive. Make this decision before your first production transaction.

Let us know if you intend to deploy AI agents for payments, settlement, or treasury. We will work through your setup with you: transaction scale, chains, custody constraints, and what self-hosted MPC looks like in your specific context.

Frequently Asked Questions