Security & Identity

Using MCP with Web3: How to secure agents making blockchain transactions

December 5, 2025

Adrien Delaroche

Web3 Principal Architect

Try Gemini 3

Our most intelligent model is now available on Vertex AI and Gemini Enterprise

At Google Cloud, we sit at a unique intersection of two transformative technologies: AI and Web3. The rise of AI agents capable of interacting with blockchains opens up a world of automated financial strategies, fast payments, and more complex scenarios like executing complex DeFi operations and bridging assets across multiple chains.

However, the practical viability of this new paradigm hinges on who hosts the agent, and who holds the private key to the operations.

The core issue is simple. Since most cryptocurrency users are not going to run their own secure servers to manage agent keys, providers are likely to turn to one of two primary architectures: A custodial model where users delegate funds to a third-party agent that controls a private key, and a non-custodial model where the agent only crafts transactions for the user to sign with its own private key.

Most of today’s examples showcase an agent directly holding a private key, and most cryptocurrency model context protocol (MCP) servers can only be used if you configure them with a private key. However, that may not be the only option.

The agent-controlled model

This model is designed for a world where users interact with agents hosted by a third party — a realistic assumption for mainstream adoption. In this scenario, you don’t give the agent your private key. Instead, the agent has its own key, and you give it an allowance to spend on your behalf.

How it works

Agent-controlled model sequence diagram.

Agent gets a wallet: The agent possesses one or multiple private keys. The private keys for these wallets are managed securely by the host of the agent, never by you.
User delegates funds: From your personal wallet (such as MetaMask, or a hardware wallet), you send a specific amount to the agent’s public address.
Agent gains autonomy: The agent now has full, autonomous control over the funds in the wallet it controls. The agent can use its key to sign and execute transactions — swapping tokens, buying NFTs, and paying another agent for data — until the pre-paid balance runs out.

The inherent risks

While this model provides automation, it introduces significant risks that shift from you to the agent and its host.

Performance risk: The agent could be bad at its job: A trading agent might execute a flawed strategy and lose the funds you delegated.
Malice risk: A poorly-designed or intentionally-malicious agent could misuse the funds. For example, the agent could send its balance to an unauthorized address. To prevent that scenario, the hosting platform should have robust safeguards, audits, and rules to constrain agent behavior. Another option is to ensure the agent funds are secure in a smart contract that guarantees how the funds are going to be used.
Security risk: The third-party host is now a custodian of your delegated funds. If their platform is hacked and the agents’ private keys are compromised, your pre-paid balance would be a primary target.

The self-hosted variant

A small minority of technically advanced users will want to run this model on a personal server. Because we’re in the nascent stages of AI agent development, this small group of developers and early adopters represents the current primary user base.

Consequently, this self-hosted model is the one most encountered in today's landscape, and it's what most crypto MCP servers are being built to cater for. In this case, it’s technically viable to give the agent a private key, because the key never leaves the user's own controlled environment.

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_-_Self-hosted_agent_model_sequence_diagr.max-1300x1300.jpg

Self-hosted agent model sequence diagram.

However, it also comes with a very high risk level. The private key can get hacked if your machine is compromised, and erratic, unauthorized agent behavior can lead to significant losses.

For example, if you say “I want to swap 500 USD for UNI”, the agent could decide to sell the UNI, or buy the UNI, mess up the slippage percentage, or buy the wrong UNI token. We recommend using this approach only for tests.

The transaction-crafter model

This is the non-custodial and fundamentally more secure alternative for most user interactions. Here, the agent never holds any of your funds. Its purpose is to do exactly the same thing as the agent-controlled model, but instead of signing and sending the key, the transaction is returned for the user to sign and send the key to the blockchain network.

How it works

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_-_Transaction_crafter_model_sequence_dia.max-1300x1300.jpg

Transaction crafter model sequence diagram.

User instructs agent: You ask the agent to perform a task, such as “swap my ETH for USDC.”
Agent crafts the transaction: The agent analyzes your query, and constructs the raw transaction, such as the swap transaction.
User signs the transaction: The agent passes this data back to you. Your wallet displays a pop-up showing exactly what you are about to do. Only you can approve and sign it with your private key.

How to build the agent with Google Cloud tools

To demonstrate this model, I built a sample agent using a suite of Google Cloud tools. The agent's reasoning is powered by the Gemini 2.0 Flash model and orchestrated using the Google Agent Development Kit (ADK). For testing, I acquired funds from the public Google Cloud Ethereum Faucet, a key resource for developers.

Developing agents using ADK is quite simple, and comes with useful features such as a web UI for simple testing and development environment, a powerful integration to Agent Engine and Google Cloud Run to easily deploy the agent in production, a simple way to run the agent as an API server for easy connection with a custom front end, and a toolbox to easily connect to MCP Servers, Agent-to-Agent (A2A) protocol, and tools such as Google search.

If you want to learn more about how to build agents using the Google Cloud stack, you can read this article.

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_cejGPDZ.max-1800x1800.jpg

The two main parts of this app are the agent that crafts transactions, and the front end that gets the crafted transaction from the agent and sends it to MetaMask for signature and sending.

The agent using Google ADK is quite simple to develop, the craft_eth_transaction function though can be quite complicated depending on the type of operations supported. These can include chains, assets, and swaps:

from google.adk.agents import Agent
from web3 import Web3

ETH_RPC_URL = "RPC URL"

# (This is the tool function defined in the next section)
def craft_eth_transaction(to_address: str, amount: float, from_address: str, chain_id: int):
   # Step 1: Fetch the sender's next transaction count (nonce)
   # Step 2: Determine transaction type (ETH transfer or smart contract call)
   # Step 3: Construct the 'data' field using ABI
   # Step 4: Assemble and return the final, unsigned transaction

# The Agent is defined with a simple, non-custodial instruction
root_agent = Agent(
   name="transaction_crafter_agent",
   model="gemini-2.0-flash",
   description="An agent that crafts Ethereum transactions for a front-end to send via MetaMask.",
   instruction=(
       "You are an agent that crafts ETH transactions. "
       "Your only job is to collect the information from the user to craft Ethereum transactions.. "
       "The sender's address will be provided to you as context, along with the chain ID."
       "Use the `craft_eth_transaction` tool to generate the transaction object. "
       "The tool will return a JSON object that is ready to be sent to MetaMask. "
       "Leave gas and gasPrice fields empty; MetaMask will set them."
       "**IMPORTANT:** After using the tool, you must present the final transaction JSON in the response, formatted exactly like this:\n"
       "   ```json\n"
       "   {\n"
       "     \"to\": \"0x...\",\n"
       "     \"from\": \"0x...\",\n"
       "     \"value\": \"0x...\",\n"
       "     \"nonce\": \"0x...\",\n"
       "     \"chainId\": \"0xaa36a7\"\n"
       "   }\n"
       "   ```\n"
   ),
   tools=[craft_eth_transaction],
)

On the client-side, the logic is clean and focused on Web3 interactions. The front-end doesn't need to know anything about large-language models (LLMs) or agent orchestration. It calls the agent's API endpoint (hosted on Google Cloud Run), gets back a standard JSON transaction object, and passes it to MetaMask.

ADK's ability to easily run the agent as an API server provides this clean separation of concerns. The two main functions on the frontend are to extract the transaction from the agent’s response and how to send it to MetaMask. Here’s an example of those functions:

/**
* Step 1: Process the agent's response to extract the crafted transaction data.
* The agent's only output is a standard, unsigned transaction object.
*/
function extractTransactionFromAgentResponse(agentEvents) {
   const functionResponse = agentEvents.find(
       e => e.content?.parts?.[0]?.functionResponse?.name === 'craft_eth_transaction'
   )?.content.parts[0].functionResponse;

if (functionResponse?.response?.success) {
       // The raw transaction object, ready for the user's wallet
       return functionResponse.response.transaction;
   }
   return null;
}

/**
* Step 2: Pass the crafted transaction to the user's wallet for execution.
* This function triggers a MetaMask pop-up, putting the user in full control.
*/
async function executeMetaMaskTransaction(txData) {
   if (!txData || typeof window.ethereum === 'undefined') {
       console.error("Invalid transaction data or MetaMask not found.");
       return;
   }

try {
       // The 'eth_sendTransaction' call asks the wallet to sign and send.
       // The private key is never exposed to our web application.
       const txHash = await window.ethereum.request({
           method: 'eth_sendTransaction',
           params: [txData], // txData is the JSON object from the agent
       });

console.log(`Transaction sent successfully! Hash: ${txHash}`);
       return txHash;

} catch (error) {
       // This error typically means the user rejected the transaction in MetaMask.
       console.error("Transaction failed or was rejected by user:", error);
   }
}

How the agent confirms intent

While the agent operation is the dialogue with the agent to reach a decision, the MetaMask pop-up is the conclusion of that conversation.

Think of it as the digital equivalent of your financial advisor explaining a strategy and then handing you the final document to sign. The signature is the deliberate, necessary confirmation that you understand and consent to the action. It can turn the agent’s recommendation into a reality with your explicit approval, providing crucial peace of mind. Especially given that an agent’s interpretation can vary wildly depending on the underlying LLM, the conversational context, and the data it has access to, it’s always good to check a wallet transaction twice before approval.

MCP servers should serve both realities

The vision of a future where agents autonomously pay other agents for services necessitates the agent-controlled model. Agents in this economy will need their own capital to operate.

However, the transaction-crafter model provides a secure bridge to that future. It can be used to safely fund an agent, or to simply execute one-off transactions for simpler operations. This flexibility is key.

From a developer’s perspective, adding this capability shouldn’t be a heavy lift. If a MCP server can already prepare and sign a transaction with a key it holds, it should be able to perform the same logic without the final signing step, returning the unsigned transaction instead. This minor change unlocks a much safer and flexible paradigm for users and can even enable more complex designs, like a dedicated “signer agent” in a multi-agent system.

Therefore, any robust MCP server designed for broad adoption should provide developers with the flexibility to build applications that can: