Pakt: A Control Layer for Safer Agentic Trading

Table of Contents

1. The Rise of AI Agents and the Question of Reliability

2. BOB’s Pakt: Safeguards for Agentic Trading

3. Pakt: A Firewall Between Agents and Users

4. Conclusion: BOB Prepares for Wider Adoption of Agentic Finance

 

 

1. The Rise of AI Agents and the Question of Reliability

AI is evolving from a tool that answers questions and organizes information into agents that access external services and carry out tasks. Meta’s personal agent Muse, unveiled in September, supports tasks such as booking travel, completing website forms, and negotiating prices. Users can specify what they want and let the agent handle the task, rather than navigating websites or contacting other parties themselves.

Yet cases are emerging in which agents act contrary to users’ intentions while carrying out these tasks. One user who asked Muse to sell a secondhand item instructed it to accept no less than $700. Although the user had selected “Allow Always” in the permission settings, they expected Muse to seek their approval before making an important decision such as accepting an offer.

Instead, Muse sent a buyer a message accepting a $600 offer and shared the meeting location without consulting the user. After discovering what had happened, the user contacted Meta for an explanation. Meta said an error had removed the digit “7” from the response sent to the buyer, displaying “700” as “00.”

Muse was able to respond to the offer and share the meeting location because the “Allow Always” setting had authorized it to send messages on the user’s behalf. The user had expected to decide whether to accept an offer and had not realized that Muse could communicate acceptance without seeking their approval.

Source: X(@MattRobbt)

In a secondhand sale like this one, there may still be time to reconfirm the price and correct a mistaken message before handing over the item. But when an agent transfers funds, enters into a contract, or trades assets, funds may have already moved or a transaction may be underway before the user notices a problem. Recovering a mistaken transfer or canceling a contract may require additional procedures, while unwinding an executed trade can incur losses from price movements as well as trading fees.

As agents gain adoption and take on more tasks involving real funds, controls that allow only user-authorized transactions to proceed will become increasingly important. This calls for an intermediary that checks orders against user-defined trading rules, including permitted assets and amount limits, and blocks orders that violate those rules before execution.

 

2. BOB’s Pakt: Safeguards for Agentic Trading

2.1 Why BOB Developed Pakt

BOB, backed by Castle Island, Coinbase Ventures, Ledger Cathay, IOSG, RockawayX and others, which has been building Bitcoin DeFi infrastructure, expects agents to progress from providing investment information to managing real funds. With that transition in mind, it developed Pakt to control how funds are used across different agents and trading services. Pakt is a financial firewall that blocks orders that violate user-defined trading rules before execution. The aim is to support the adoption of agentic trading by allowing users to benefit from their chosen agent’s market analysis and trading capabilities while ensuring that funds are used only under approved rules.

BOB experimented with executing trades requested through chat by connecting agents to Gateway, which supports cross-chain swaps of native BTC. During development, agents occasionally mishandled decimal places and swapped more than intended, or failed to apply slippage limits correctly. These problems led BOB to conclude that it needed controls over how funds were used before making the service available to users. The belief is that trust is going to be the biggest barrier to overcome before people feel comfortable giving agents access to their money.

Seeing that the controls developed for Gateway could also apply to other agent-driven trading, BOB developed them into a standalone product, Pakt. BOB aims to expand integrations so users can work with familiar agents and existing trading accounts, while also providing these controls to businesses building agent-based financial services.

2.2 Applications for Individual Users and Trading Service Developers

Individual users can connect Pakt to an agent they already use and describe their strategy and limits in natural language. This enables assisted automation: the agent prepares and executes orders within user-approved rules and limits. Users can remain involved in key investment decisions while reducing the repetitive work involved in trading.

For example, a user seeking to maintain fixed portfolio weights can have an agent monitor changes in prices and holdings and execute the necessary trades. If the agent tries to buy an asset the user has not permitted or exceed the specified position size or leverage limits while rebalancing the portfolio, Pakt blocks the order.

For developers and financial platforms offering this trading experience as a service, Pakt can provide a shared mechanism for managing agents’ permissions to use funds. Trading agent developers can integrate Pakt to enforce trading rules and focus on market analysis and strategy implementation. Wallets and exchanges can use it to apply each user’s trading rules when adding agentic trading to existing accounts.

 

3. Pakt: A Firewall Between Agents and Users

3.1 An Intermediary That Controls Agent Trading

Pakt is a financial firewall that checks agent-generated orders against user-approved trading rules and provides signatures only for orders that comply. It connects to agents powered by large language models (LLMs), including Claude, GPT, Gemini and anything else that speaks MCP, while the agents handle market analysis and strategy development.

Users can specify trading rules themselves or describe their strategy in natural language and have an agent use Pakt to draft the corresponding rules and limits. These cover three areas: trades (assets, venues, size, leverage, margin and collateral), account state (minimum liquid reserves, health floor and equity floor), and information sources (the criteria for trusting price data and how fresh that data must be). Once the draft is ready, the user follows a link provided by the agent to the Pakt dashboard, reviews the rules, and signs to approve activation. Pakt blocks orders that breach these rules, whether the agent hallucinates, has a bug, misunderstands an instruction, or is compromised through a hack or prompt injection.

Orders prepared by the agent are sent to Pakt before being submitted to the exchange. Pakt gathers timestamped account data and runs a policy program that checks the proposed action against every rule. Even if an individual order is within its size limit, Pakt refuses it if execution would cause the total position size or leverage to exceed the user’s limits. If the order passes, Pakt returns a signature and the agent submits the signed order to the exchange. Pakt does not place orders itself. Every decision, approved or refused, produces a verifiable receipt.

Records of orders refused by Pakt. Source: YouTube(@BuildOnBitcoin)

The agent does not receive the private keys used for trading, so it cannot independently sign and execute an order that Pakt has rejected. Funds remain in the user’s existing trading accounts and wallets, and the user retains the authority to withdraw them. Users can therefore reduce the burden of reviewing every agent-generated order while retaining control over the assets traded and the amount invested.

Pakt currently supports perpetuals trading on Hyperliquid and is recruiting beta participants who trade from chat, AI builders, experienced traders securing flows they already run, and wallets, exchanges and platforms. It is also pursuing integrations with other trading services, including centralized exchanges like Binance and Coinbase, as well as platforms such as Robinhood. Broader support could give users more options for deploying agents through their existing accounts.

3.2 Strategy Privacy and Trade Verification with ZK and TEEs

To review an agent-generated order, Pakt needs trading information such as the user’s account balance and positions. Disclosing all of this information externally, however, could reveal the strategy through trade timing or portfolio weights. Pakt uses zero-knowledge (ZK) proofs and trusted execution environments (TEEs) to verify that orders were checked against user-approved rules while limiting disclosure of detailed trading records.

Pakt checks an order using the user-approved policy program and generates a ZK proof of the result. The proof establishes the outcome without revealing all the data used to perform the check. For example, if a user sets a maximum leverage of 3x, a proof can demonstrate that an order complies with this limit without disclosing every position and balance.

The proof is then verified within a TEE, a hardware region protected against outside access and tampering. The TEE checks that the proof is valid, that the user-approved policy program was used, and that the order checked is the same one to be signed. Only when verification succeeds and the trade is permitted does the TEE authorize a separate restricted execution signer to sign. The signer checks this authorization before signing the order. Orders that violate the rules or fail verification do not receive a signature.

The same approach lets users prove their profit and loss (PnL) and trading volume without revealing individual trades. A fund can show it operated within the risk limits agreed with investors, and a trader can publish a verifiable track record without exposing their strategy. Investors can assess returns and compliance with agreed trading rules without requesting detailed trading records, and fund managers face less pressure to disclose their strategies to substantiate performance.

 

4. Conclusion: BOB Prepares for Wider Adoption of Agentic Finance

As agents progress from providing information to using external services and executing transactions, the scope of the permissions users grant them becomes increasingly important. The Muse case illustrates how the approval process a user expects can differ from the authority an agent can actually exercise. In finance, that gap can lead to fund transfers and losses, creating a need for mechanisms that enforce user-defined trading rules in actual transactions.

Pakt performs this role between agents and trade execution. Its controls cover individual orders as well as risk management across all positions, blocking trades that breach user-defined rules even if the agent is compromised through a hack or prompt injection. By adding privacy-preserving verification with ZK proofs and TEEs, it also addresses traders’ need to substantiate performance while protecting their strategies. Together, these controls address concerns about the use of funds, security, and strategy disclosure, making Pakt a practical option for users looking to adopt agentic trading.

Through Pakt, which grew out of problems encountered in processing real trades, BOB is building an environment in which agents’ capabilities can be applied to asset management. As LLMs advance rapidly and agentic finance expands, demand may grow for tools that protect users’ funds and strategies across different trading environments. As Pakt connects with wallets, exchanges, and other financial services, it could broaden its role as infrastructure supporting agentic trading.