SlowMist × Bitget AI Security Report: Is It Really Safe to Hand Your Money to AI Agents Like “Lobster”?

1. 背景

With the rapid development of large language model (LLM) technology, AI Agents are evolving from simple intelligent assistants into automated systems capable of autonomously executing tasks. This transformation is particularly evident within the Web3 ecosystem. An increasing number of users are beginning to experiment with AI Agents for market analysis, strategy generation, and automated trading, turning the concept of a “7×24 automated trading assistant” into a tangible reality. Following the launch of multiple AI Skills by Binance and OKX, Bitget has also introduced the Skills resource hub, Agent Hub. Agents can now directly integrate with trading platform APIs, on-chain data, and market analysis tools, thereby taking on some of the trading decision-making and execution tasks that were previously handled manually.

Compared to traditional automated scripts, AI Agents possess stronger autonomous decision-making capabilities and more complex system interaction abilities. They can access market data, call trading APIs, manage account assets, and even extend their functional ecosystem through plugins or Skills. This enhancement in capability significantly lowers the barrier to entry for automated trading, allowing more ordinary users to begin using automated trading tools.

However, the expansion of capabilities also means an expansion of the attack surface.

In traditional trading scenarios, security risks typically focus on issues like account credentials, API Key leaks, or phishing attacks. Within the AI Agent architecture, new risks are emerging. For example, prompt injection attacks can influence an Agent’s decision-making logic; malicious plugins or Skills can become new entry points for supply chain attacks; and improper configuration of the runtime environment can lead to the misuse of sensitive data or API permissions. Once these issues are combined with automated trading systems, the potential impact may extend beyond information leaks to directly cause real financial losses.

Simultaneously, as more users connect AI Agents to their trading accounts, attackers are quickly adapting to this change. New types of scams targeting Agent users, malicious plugin poisoning, and API Key abuse are gradually becoming new security threats. In the Web3 context, asset operations are often high-value and irreversible. Once an automated system is misused or misled, the risk impact can be further amplified.

Based on this background, SlowMist and Bitget have jointly authored this report, systematically analyzing the security issues of AI Agents across multiple scenarios from the dual perspectives of security research and trading platform practice. We hope this report can provide security references for users, developers, and platforms, helping to promote a more robust development of the AI Agent ecosystem that balances security and innovation.

2. Real Security Threats of AI Agents | SlowMist

The emergence of AI Agents is shifting software systems from “human-led operation” towards “model-involved decision-making and execution.” This architectural change significantly enhances automation capabilities but also expands the attack surface. From a current technical structure perspective, a typical AI Agent system usually includes components such as the user interaction layer, application logic layer, model layer, tool calling layer (道具s / Skills), memory system, and underlying execution environment. Attackers often do not target a single module but attempt to gradually influence the Agent’s behavioral control through multi-layered pathways.

1. Input Manipulation and Prompt Injection Attacks

In the AI Agent architecture, user inputs and external data are typically directly incorporated into the model’s context, making prompt injection a significant attack vector. Attackers can craft specific instructions to induce an Agent to perform actions it should not normally trigger. For example, in some cases, simply using chat instructions can induce an Agent to generate and execute high-risk system commands.

A more complex attack method is indirect injection, where attackers hide malicious instructions within web content, document descriptions, or code comments. When the Agent reads this content during task execution, it may mistakenly treat it as legitimate instructions. For instance, embedding malicious commands in plugin documentation, README files, or Markdown files can cause the Agent to execute attack code during environment initialization or dependency installation.

The characteristic of this attack mode is that it often does not rely on traditional vulnerabilities but exploits the model’s trust mechanism for contextual information to influence its behavioral logic.

2. Supply Chain Poisoning in the Skills / Plugin Ecosystem

In the current AI Agent ecosystem, plugin and skill systems (Skills / MCP / Tools) are important ways to extend Agent capabilities. However, this type of plugin ecosystem is also becoming a new entry point for supply chain attacks.

SlowMist’s monitoring of the official plugin center ClawHub for OpenClaw has revealed that as the number of developers grows, some malicious Skills have begun to infiltrate the platform. After conducting correlation analysis on the IOCs of over 400 malicious Skills, SlowMist found that a large number of samples point to a few fixed domains or multiple random paths under the same IP, showing clear characteristics of resource reuse. This resembles organized, batch attack behavior.

In OpenClaw’s Skill system, the core file is usually SKILL.md. Unlike traditional code, these Markdown files often serve as “installation instructions” and “initialization entry points.” However, in the Agent ecosystem, users often directly copy and execute them, forming a complete execution chain. Attackers only need to disguise malicious commands as dependency installation steps, such as using curl | bash or Base64 encoding to hide the real instructions, to induce users to execute malicious scripts.

In actual samples, some Skills employ a typical “two-stage loading” strategy: the first-stage script is only responsible for downloading and executing the second-stage payload, thereby reducing the success rate of static detection. Taking a Skill with a high download count, “X (Twitter) Trends,” as an example, its SKILL.md contains a hidden Base64-encoded command.

Decoding reveals its essence is to download and execute a remote script:

The second-stage program then impersonates a system dialog to obtain the user’s password, collects local machine information, desktop documents, and files from the download directory in the system’s temporary folder, ultimately packaging and uploading them to a server controlled by the attacker.

The core advantage of this attack method is that the Skill shell itself can remain relatively stable, while the attacker only needs to change the remote payload to continuously update the attack logic.

3. Agent Decision-Making and Task Orchestration Layer Risks

In the application logic layer of an AI Agent, tasks are typically broken down by the model into multiple execution steps. If an attacker can influence this decomposition process, it may cause the Agent to exhibit abnormal behavior while performing legitimate tasks.

For example, in business processes involving multi-step operations (such as automated deployment or on-chain transactions), attackers can tamper with key parameters or interfere with logical judgments, causing the Agent to replace target addresses or execute additional operations during the execution flow.

In a previous SlowMist security audit case, malicious prompts were injected into the MCP return to pollute the context, thereby inducing the Agent to call a wallet plugin to execute an on-chain transfer.

The characteristic of this type of attack is that the error does not originate from the model-generated code but from the tampered task orchestration logic.

4. Privacy and Sensitive Information Leakage in IDE / CLI Environments

As AI Agents are widely used for development assistance and automated operations, a large number of Agents now run in IDEs, CLIs, or local development environments. These environments typically contain a wealth of sensitive information, such as .env configuration files, API トークンs, cloud service credentials, private key files, and various access keys. Once an Agent can read these directories or index project files during task execution, it may inadvertently incorporate sensitive information into the model’s context.

In some automated development workflows, Agents might read configuration files in the project directory during debugging, log analysis, or dependency installation. Without clear ignore policies or access controls, this information could be recorded in logs, sent to remote model APIs, or even exfiltrated by malicious plugins.

Furthermore, some development tools allow Agents to automatically scan code repositories to build contextual memory, which may also expand the scope of sensitive data exposure. For example, private key files, mnemonic backups, database connection strings, or third-party API Tokens could be read during the indexing process.

This issue is particularly prominent in Web3 development environments, as developers often store test private keys, RPC Tokens, or deployment scripts locally. Once this information is obtained by malicious Skills, plugins, or remote scripts, attackers may further control developer accounts or deployment environments.

Therefore, in scenarios where AI Agents integrate with IDEs / CLIs, establishing clear sensitive directory ignore policies (e.g., mechanisms like .agentignore, .gitignore) and permission isolation measures are crucial prerequisites for reducing data leakage risks.

5. Model Layer Uncertainty and Automation Risks

AI models themselves are not completely deterministic systems; their outputs have a certain degree of probabilistic instability. The so-called “model hallucination” refers to the model generating seemingly plausible but actually incorrect results when lacking information. In traditional application scenarios, such errors typically only affect information quality. However, in the AI Agent architecture, model output can directly trigger system operations.

For example, in some cases, a model, when deploying a project, did not query the real parameters but generated an incorrect ID and proceeded with the deployment process. If a similar situation occurs in on-chain transaction or asset operation scenarios, erroneous decisions could lead to irreversible financial losses.

6. High-Value Operation Risks in Web3 Scenarios

Unlike traditional software systems, many operations in the Web3 environment are irreversible. For example, on-chain transfers, token swaps, liquidity provision, and smart contract calls, once signed and broadcast to the network, are typically difficult to revoke or roll back. Therefore, when AI Agents are used to execute on-chain operations, their security risks are further amplified.

In some experimental projects, developers have begun to let Agents directly participate in on-chain trading strategy execution, such as automated arbitrage, fund management, or DeFi operations. However, if the Agent is affected by prompt injection, context pollution, or plugin attacks during task decomposition or parameter generation, it may replace target addresses, modify transaction amounts, or call malicious contracts during the transaction process. Additionally, some Agent frameworks allow plugins direct access to wallet APIs or signing interfaces. Without signature isolation or manual confirmation mechanisms, attackers could even trigger automatic transactions through malicious Skills.

Therefore, in Web3 scenarios, fully binding AI Agents to asset control systems is a high-risk design. A safer model typically involves having the Agent only responsible for generating trading suggestions or unsigned transaction data, while the actual signing process is completed by an independent wallet or manual confirmation. Simultaneously, combining mechanisms like address reputation detection, AML risk control, and transaction simulation can also help mitigate the risks associated with automated trading.

7. System-Level Risks from High-Privilege Execution

Many AI Agents are deployed with high system privileges, such as accessing the local file system, executing shell commands, or even running with root permissions. Once an Agent’s behavior is manipulated, its impact range may extend far beyond a single application.

SlowMist has tested binding OpenClaw with instant messaging software like Telegram to achieve remote control. If the control channel is compromised by an attacker, the Agent could be used to execute arbitrary system commands, read browser data, access local files, or even control other applications. Combined with the plugin ecosystem and tool-calling capabilities, such Agents, to some extent, already possess characteristics of “intelligent remote control.”

Overall, the security threats of AI Agents are no longer confined to traditional software vulnerabilities but span multiple dimensions including model interaction layers, plugin supply chains, execution environments, and asset operation layers. Attackers can manipulate Agent behavior through prompts, implant backdoors at the supply chain layer via malicious Skills or dependencies, and further expand their attack impact in high-privilege runtime environments. In Web3 scenarios, due to the irreversible nature of on-chain operations and their involvement with real asset value, these risks are often further amplified. Therefore, in the design and use of AI Agents, relying solely on traditional application security strategies is insufficient to cover the new attack surface. It is necessary to establish a more systematic security protection system across aspects such as permission control, supply chain governance, and transaction security mechanisms.

3. AI Agent Trading Security Practices | Bitget

As AI Agent capabilities continue to strengthen, they are no longer just providing information or assisting with decisions but are beginning to directly participate in system operations and even execute on-chain transactions. This change is particularly evident in the 暗号 trading scene. More and more users are experimenting with AI Agents for market analysis, strategy execution, and automated trading. When Agents can directly call trading interfaces, access account assets, and place orders automatically, their security issues further transform from “system security risks” into “real asset risks.” When AI Agents are used for actual trading, how should users protect their accounts and funds?

Based on this, this section, authored by the Bitget security team, combines practical experience from the trading platform to systematically introduce key security strategies for automated trading using AI Agents, covering aspects such as account security, API permission management, fund isolation, and transaction monitoring.

1. Main Security Risks in AI Agent Trading Scenarios

2. Account Security

With the advent of AI Agents, the attack path has changed:

• No need to log into your account—just need to get your API Key.
• No need for you to notice—Agents run 7×24 automatically, abnormal operations can persist for days.
• No need to withdraw—directly trade assets to zero within the platform, which is also an attack target.

The creation, modification, and deletion of API Keys require actions through a logged-in account—account compromise means loss of Key management control. The security level of your account directly determines the security ceiling for your API Keys.

What you should do:

• Enable Google Authenticator as the primary 2FA, not SMS (SIM cards can be hijacked).
• Enable Passkey passwordless login: Based on FIDO2/WebAuthn standards, public-private key encryption replaces traditional passwords, making phishing attacks architecturally ineffective.
• Set an anti-phishing code.
• Regularly check the device management center; immediately log out any unfamiliar devices and change your password.

3. API Security

In the AI Agent automated trading architecture, the API Key serves as the Agent’s “execution permission credential.” The Agent itself does not directly hold account control; all operations it can perform depend on the permission scope granted to the API Key. Therefore, the API permission boundary determines both what the Agent can do and the potential extent of loss in the event of a security incident.

Permission Configuration Matrix—Minimum Permissions, Not Convenience Permissions:

On most trading platforms, API Keys typically support various security control mechanisms. If used properly, these mechanisms can significantly reduce the risk of API Key abuse. Common security configuration recommendations include:

Common user mistakes:

• Pasting the main account API Key directly into Agent configuration—exposing the main account’s full permissions.
• Clicking “Select All” for business types for convenience, effectively opening up all operational scopes.
• Not setting a Passphrase, or using the same Passphrase as the account password.
• Hardcoding API Keys in code, which get scraped by bots within 3 minutes after being pushed to GitHub.
• Authorizing the same Key to multiple Agents and tools simultaneously; if any one is compromised, all are exposed.
• Not immediately revoking a leaked Key, giving attackers a continued exploitation window.

Key Lifecycle Management:

• Rotate API Keys every 90 days; delete old Keys immediately.
• Immediately delete the corresponding Key when decommissioning an Agent; leave no residual attack surface.

この記事はインターネットから得たものです。 SlowMist × Bitget AI Security Report: Is It Really Safe to Hand Your Money to AI Agents Like “Lobster”?

Related: Is There More to Kyle Samani’s Exit from the Crypto Industry?

Author｜Azuma (@azuma_eth) Just days after Multicoin Capital co-founder Kyle Samani announced his departure from the crypto industry, the goodwill he had accumulated over the years has been rapidly eroded. “Burning Bridges” is Truly Disgusting Objectively speaking, Kyle Samani has made positive contributions to the cryptocurrency industry over the years. Whether it’s the continuous financial support for early-stage projects (regardless of motive, focusing on impact) or the narrative guidance and ideological evangelism at the conceptual level, he has directly or indirectly influenced the industry’s direction. From a results-oriented perspective, Kyle Samani indeed achieved “massive results” in the crypto industry that are unimaginable to most. Based on this alone, it’s quite reasonable for Hasseb Qureshi to call him the “best investor in the industry” or for Mable to label him a “top…