Understanding Authorization Requirements of AI Trading Agents
Research Competition
How Can an AI Agent Prove It Was Allowed to Trade, Without Ever Holding the Keys?
How can an AI agent prove it was allowed to make a trade, without ever being handed the keys? This is the central authorization problem facing Agentic AI trading systems operating on blockchain networks: an Agent must demonstrate that its actions are merited, that it is not running compromised code, and that it possesses enough funds to carry out a trade, all without exposing a wallet’s contents. This paper surveys the strategies used to answer that question, from soft guardrails such as Large Language Model (LLM) prompt filtering to harder architectural controls such as zero-knowledge proofs and Account Abstraction (AA) protocols, and weighs how much risk each removes on its own. The methodology behind data collection involved research of current documentation on network protocols as well as the findings of previous research, with sources ranging from reports of individual incidents to meta-analyses covering large amounts of research. The conclusion reached is that authorization and custody are separate problems: physical disconnection of private keys, on-chain augmentation, and temporary sessions each create a safer environment, but none of them, alone or combined, removes the need for continued human-in-the-loop verification to fully limit Agentic related faults. Despite these risks, Agentic AI trading has the potential to outperform current traditional trading systems; however, the new risks and complexities demand layers of cryptographic, hardware, and limited capability environments to limit leakage and risk associated with the new frontier of AI Agentic application.
1. Architecture of Agentic Authorization
Before any Agentic AI performs a trade it must have data on the current state of the market. One method for an agent gathering current market data is through an Application Programming Interface (API) that displays essential information, such as Decentralized Exchange (DEX) rates. Typically, Agents will pay the API fees through x402 open payment protocols pulling from a limited Agentic Wallet. The main mechanism by which Agents connect with outside information is through a Model Context Protocol (MCP) that connects an Agent to APIs, brokerages, trading platforms, and other connections beyond the Agent. A large quantity of wallets trading on common networks such as Bitcoin (BTC) and Ethereum (ETH) trade using public and private keys in order to authenticate trades (the mechanisms of these systems will not be covered here). One of the major problems with Agentic authorization is how to verify a transaction without allowing an Agent access to a wallet’s private key. This is because, wallet’s private keys can be leaked and possibly liquidated, giving an attacker unlimited access to a wallet. Also, giving an Agent a private key has this same effect and could have stern consequences.
Account Abstraction (AA) is a possible method of verification without giving an Agent a wallet’s private key. It aims to solve the problem of an Agent having unlimited access to a user’s private key by trading through a smart-contract, an on-chain program that an Agent can interact with and run functions bound by scoped rules, instead of directly trading from a wallet.[1] Code is bundled and sent to the blockchain limiting transactions to pre-defined functions allowing an Agent to trade within specified margins. This protocol for smart contracts, on the Ethereum network, is defined by ERC-4337.[2] By abstracting account access into a smart contract, the Agentic AI can only perform within the scopes and functions defined. Moreover, hard-coded spending limits can be written into smart-contracts preventing an agent from wiping an account. This limits the Agent’s access to the account, prevents loss beyond what is allowed within the contract, and limits an attacker from accessing anything beyond the smart contract. Obviously, this leaves vulnerability still lying within the smart contract; however, the code written into smart contracts is predefined and would mitigate effects.[3] Authorization is given to an Agent to execute what has been laid out in the smart-contract.
Since smart-contract code is bundled and resides on the block-chain, an alternative method is needed in order to hide proprietary trading strategies. Zero-knowledge proofs (zk-proofs) allow for an Agentic AI to prove that it is authorized to execute a trade without existing entirely on the blockchain. Essentially a proof is written into an Agent’s execution order and sent to a verification smart-contract living on the block-chain. The verification smart contract checks if the proof is present and if it is, the smart contract knows it can trust the order from the Agent. It would be very unlikely that an injection could create this same zk-proof therefore when the smart contract receives a message with a proper zk-proof, it can trust the Agent.[4] This allows an agent to prove its legitimacy without having to send any information about itself or its code.
2. Spectrum of Guardrails
In Agentic trading there exists a spectrum of guardrails that can be used to limit financial risk while using an Agent. These range from soft LLM guardrails that limit prompts all the way to manual human interference for every action completed by an Agent.
2.1 Probabilistic Guardrails for LLMs
One of the main security threats with the use of an LLM is malicious prompt injection or API hijacking. These occur because LLMs cannot perfectly interpret between data and instructions coded into messages. For example, in May 2026, an attacker encoded instructions in morse code to send tokens to a specific address. The probabilistic guardrails of the LLM that should have caught these malicious instructions, and prevented their execution, did not detect them and the account was sent these tokens.[5] One preventative method that could be used before data is sent to an LLM is to run it through a program such as Nvidia’s NeMo guardrail library to validate a message for unsafe content before it reaches an LLM. LLMs themselves, can be trained in order to detect malicious prompts; however, there is no reliable way to prevent jailbreaks.[6] Defense would then rely on the understanding that instructions given to a model will eventually bypass probabilistic guardrails suggesting that LLMs should only be given limited access to a wallet or market through abstraction to prevent catastrophic breaches. By limiting the capabilities of a LLM an attacker that will eventually find a way to jailbreak a LLM will only be able to complete operations within a limited scope of authorization given to an LLM. Another solution would be to have a human-in-the-loop form of verification before authorizing an LLM to interact with a wallet or market.
2.2 On Chain Determinism
If LLMs can have their logical limitations broken, steps in between an LLM and the blockchain must be implemented in order to limit these effects. Time locks, blast radius mitigation, and multiple separated levels of verification should be used in order to limit an Agent’s capabilities. As mentioned previously with zk-proofs, validation occurs separately and a model or Agent is authorized outside of itself. An implementation of ERC-7579 could create a standardized smart-account validation scheme that could be used with zk-proofs, allowing the setup of key verification to be more standard across the Agentic economy.[7] Some methods of validation include sanitization of prompts to remove non-text or non-numerical information, essentially filtering out code or other instructions. This can allow for an LLM to detect a faulty prompt more effectively. Hooks are custom logic implementations that can be performed before and, or after interaction with a smart contract defined by ERC-4337. If a hook or validation process returns an error, the interaction could fall back to human-validation to ensure its intent. A hook could be created in order to only execute functions within a margin of risk, if an Agent wishes to exceed that risk, a hook could call for human verification before the execution is performed. Time locks can be enacted in order to delay an execution for a certain amount of time, similar to how credit card transactions are approved after a certain amount of time. All of these methods are based on the use of abstraction and have their primary safety addition relying on predefined limits. Due to the nature of logic determinism, these can fail due to the same reason as Probabilistic guardrails of LLMs. Eventually the logic in the hooks can fail, their main mechanisms as guardrails are to limit effects, not entirely prevent them.
2.3 Hardware Security Modules (HSM)
Another alternative to on-chain security protocols is the use of a physical hardware security modules that acts as a barrier in between a prompt and a wallet’s physical keys.[8] As outlined by NIST, HSMs are tamper resistant devices that lay between an Agent and a wallet’s keys. All signatures are written on the device and a wallet’s keys never leave it without encoding. This prevents a private key being leaked by an agent and requires an agent to first communicate with the device, preventing overstepping. This adds another authorizational step before an Agent is approved for an action and can allow for spend-limits, white-listed addresses, and multi-signature requirements between different Agents validating each other.[9]
2.4 Human-in-the-Loop
The most analogous to the modern situation is to have a human give the final approval before a transaction is executed. There are many ways in which a human-in-the-loop process could work and the decision on implementation depends on risk tolerance and desired alpha generation. A human-in-the-loop strategy centers around having a human verify and authorize an execution before it is processed. The degree to which this method can be employed depends on a continuum based upon the risk/reward of a decision. The Human AI-Governance framework (HAIG) is a dynamic governance continuum based on the dynamics of trust (risk) and utility (reward).[10] Meaning that the degree of automation should be determined on a case-by-case basis based upon factors of risk and efficacy. By completely denying or accepting Agents to trade, one adds extraneous risk or loses out on potential earnings. To understand where Agentic trading falls on this continuum, it is essential to weigh the pros and cons and find where on the HAIG framework a situation lies.
3. Potential Advantages of Fully Autonomous Agentic Trading
On the one hand, research experiments conducted on historical market datasets report alpha generation with Agentic trading relative to traditional systems. These results come from backtested research settings rather than live deployment, and should not be read as indicative of live trading performance. Which could indicate possible, albeit risky, potential of LLMs with evolutionary search for factor discovery.[11] Xiao et. Al noted multiple experiments proving Agentic trading’s superiority over traditional models, with significant gains in Sharpe ratio, cumulative and maximum drawdown.[12] There are many possible factors contributing to these gains including decreased reaction times to price fluctuations, fast analysis of data, high speed algorithmic generation and back-testing. In the case of human-in-the-loop authentication, there is high potential that alpha generation will be lost due to delays caused by bottlenecks in decision making, decision making fatigue, and incompetence.
4. Potential Risks of Fully Autonomous Agentic Trading
On the other hand, when widespread use of LLMs based on the same data sets running very similar operations, trading strategies and decision making overlap will begin to occur.[13] If this is to be the case, Gong (2026) raises the concern that correlated agent behaviour could contribute to sudden volatility in certain assets.[14] The specific mechanism by which this would produce bubble formation is not yet empirically established. Moreover, the use of LLMs introduces the risks mentioned previously such as context manipulation, API and prompt injection, leaking of confidential trading strategies, and hallucinations. To the last point, cascading failures such as “degeneration of thought” where an LLM enters a feedback loop of poor decision making could cause massive evaporation of assets leading to a firm crash. The question of how a decision involving funds is to be authorized further comes into question when investors are brought into question. Are the risks associated with Agentic trading and the use of LLM acceptable when trading other people’s money?
5. Risk Factored Approach
Regarding the high growth potential of the application of LLMs and Agentic trading, it would be counter-productive to completely dismiss the utilization of Agents as a result of their potential downsides. While it would be bullish to blindly trust their methods, the strategic implementation of their research potential and increased efficiency makes their implementation worth it. From the perspective of a HAIG–like approach, the Agent could be used in order to facilitate low-risk trades autonomously with larger and higher risk transactions only being executed with human authorization. However, this still leaves large vulnerabilities as mentioned previously. Once further widespread security measures are taken and these vulnerabilities are mitigated, Agentic trading could have some risk reduced. At this current place in time, it may be more beneficial to limit the use of LLMs to research and back-testing to find new trading algorithms as opposed to trading itself, limiting trade execution to human authorization before the Agent completes the transaction. If complete autonomy is given to an Agent, certain stop losses must also be implemented in order to limit the cascading effect of hallucinations or thought degradation, or coinciding volatility. Authenticity of a trade can be proved with zk-proofs operating within a smart contract; however, this still entails significant technical and operational risk. Nothing in this paper constitutes financial or investment advice. A HAIG approach applied to a case-by-case basis allows one to analyze the trust in the system versus its potential upside.
Hardware Wallets for Account Abstraction
As mentioned previously, leakage of a wallet’s private key when using an Agent can be detrimental and lead to the liquidation of an entire wallet. A solution to mitigate this is to keep private keys separate and out of possible reach of an Agent. An effective way of accomplishing this is to keep private keys on a secure physical device that is not even connected to the internet. This way all communication to the block chain is always hashed and private keys remain secure. This is the inherent functionality of Ledger devices and is the principle position they hold toward security. The safest way to have a wallet is to make sure that private keys remain private. This position coincides with the previous conclusion that Agents must be authenticated by different means than being given a wallet’s private key and signing their own transaction. By keeping private keys entirely separate from Agents, as is the case with hardware wallets, one does not run the risk of their private key becoming leaked such as in the case demonstrated by Liu et. Al.[15] This demonstrates the importance of maintaining a strong disconnect between an Agent and the assets it is trading through Account Abstraction with a physical wallet providing one solution for this.
This connects directly to the conclusion reached elsewhere in this paper: authorization must be provable without ever handing the key itself to the Agent. Ledger’s own position, that trust should be anchored in something physical rather than in code, is a specific case of that same principle applied to custody. A hardware wallet does not resolve the authorization problem by itself, since it says nothing about whether a given trade should have been approved in the first place, but it does close off one failure mode that no purely on-chain or software-based scheme can fully rule out: a leaked or misused private key. Seen this way, hardware isolation and Agentic guardrails are not competing solutions but complementary layers, one securing the credential, the other governing what the Agent is allowed to do with it.
6. Conclusion
As the Agentic AI trading economy expands rapidly, questions to how an Agent can prove that it was authorized to commit a trade come up. This paper aimed to answer these questions of financial and cyber security when it comes to this novel market. The main principles for Agentic authorization center around two central ideas: prove legitimacy of an Agent’s request without giving the Agent access to a wallet’s private key, and to limit risk due to a leak of a private key, agent errors, or malicious intent. The main protocols suggested to fulfill these aims include the use of zk-proofs, smart-contracts and Account Abstraction, the use of guardrails, and human-in-the-loop protocols. The use of smart-contracts was suggested in order to define the scope of an Agent, limiting its or an attackers capabilities. In order to keep proprietary trading systems discrete, it was noted that a zk-proofs could be used to keep code private while still operating through a verification smart-contract. Smart-contracts may prove to be an important form of security and a main point of interaction between AI Agents and the blockchain moving forward.
Lastly, a risk factored approach to human-in-the-loop problem of Agentic trading was analyzed. The pros and cons of fully autonomous trading Agents were weighed, the conclusion: the degree to which autonomy can be utilized is dependent on perceived risk and reward. Research results suggest AI agents can outperform traditional strategies in backtested settings; however, they bring notable risks. Therefore, it was determined that authentication of trades may still reside in the hands of human verification. The implementation of zk-proofs and account abstraction can create strong methods of authorization but it still leaves the Agent to make good decisions. The only way to mitigate these particular risks: human verification.
Listed alphabetically as in the source manuscript; bracketed numbers show where each is cited in the text above.
- [3] Agentic wallet | ledger. (2026, June 2). Ledger. ledger.com/academy/glossary/agentic-wallet
- [13] Aldridge, I., & Krawciw, S. (n.d.). AI Governance for Institutional Readiness in Finance. arxiv.org/abs/2608.02311
- [5] Arntz, P. (2026, August 25). Grok fooled into stealing user chat, location data, and more. Malwarebytes. malwarebytes.com/blog/ai/2026/08/encrypted-instructions-can-fool-ai-assistants-like-grok-and-gemini
- [8] Barker, E. (2020). Recommendation for key management: Part 1 – general. NIST Special Publication 800-57 Part 1 Revision 5. doi.org/10.6028/nist.sp.800-57pt1r5
- [2] Buterin, V. (2021, September 29). ERC-4337: Account abstraction using Alt Mempool. Ethereum Improvement Proposals. eips.ethereum.org/EIPS/eip-4337
- [6] Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A., & Tramèr, F. (2025). Defeating prompt injections by design. arXiv. arxiv.org/abs/2503.18813
- [9] for, O. (2025). ISO/IEC 19790:2025. ISO. iso.org/standard/82423.html
- [14] Gong, H. (2026, April). AI Agents in Financial Markets: Architecture, Applications, and Systemic Implications. arXiv. arxiv.org/html/2603.13942v3
- [4] Gupta, P., & Engineer. (2026, May 6). Trust without disclosure: Why zero-knowledge proofs could help build trust in AI agents. American Express Technology. americanexpress.io/trust-without-disclosure-why-zero-knowledge-proofs-could-help-build-trust-in-ai-agents
- [1] Introduction to smart contracts | ethereum.Org. (2025). Ethereum.Org. ethereum.org/developers/docs/smart-contracts
- [15] Liu, H. (2026, April 9). Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain. arxiv.org/pdf/2604.08407
- [11] Luo, H., Ko, H., & Sun, D. (2025). NeurIPS EvoAlpha: Evolutionary alpha factor discovery with large language models. Nips.Cc. nips.cc/virtual/2025/loc/san-diego/132561
- [12] Xiao, Y., Sun, E., Luo, Di, & Wang, W. (2025). ICML TradingAgents: Multi-agents LLM financial trading framework. Icml.Cc. icml.cc/virtual/2025/49302
- [7] zeroknots, Konrad Kopp, Taek Lee, Fil Makarov, Elim Poon, & Lyu Min. (2023, December 14). ERC-7579: Minimal modular smart accounts [DRAFT]. Ethereum Improvement Proposals. eips.ethereum.org/EIPS/eip-7579
- [10] Zeynep Engin. (2025). Human-AI governance (HAIG): A trust-utility approach (2505.01651V4). arXiv. doi.org/10.1016/j.jrt.2026.100167
