How Do AI Agents Create New Enterprise Security Risks? Understanding Tool Calls and Permission Boundaries

On November 3, 2026, Binance released a Preliminary Investigation Statement regarding the security incident on October 29. The statement disclosed that attackers compromised engineers' devices with malware and used internal AI tools to further expand their access. According to the statement, the attack ultimately involved unauthorized access to the internal wallet signing service, affecting approximately $6.34 billion in digital assets. However, the statement did not disclose the complete architecture of the internal AI tools, nor did it confirm that the attack exploited vulnerabilities in a large language model itself or involved prompt injection.

This incident raises an important enterprise security question: When an AI Agent can access more internal tools and sensitive systems, how should enterprises distinguish between information-processing permissions and actual operational permissions? Starting with how AI Agents call tools, this article explains permission boundaries, prompt injection, credential management, and lateral movement risks, and analyzes the security controls enterprises can adopt.

Key Takeaways

• AI Agents can do more than generate text. They may also execute code, read files, access APIs, or operate internal enterprise systems through tool calls.

• Binance's preliminary investigation statement, released on November 3, 2026, stated that attackers used compromised engineers' devices and internal AI tools to gain further access to other engineers' devices and permissions.

• One of the core security risks of AI Agents is converting information from external or low-trust environments into actions with actual execution privileges.

• Prompt injection, malicious tool outputs, excessive permissions, and credential leaks can compound one another. However, not every attack involving AI tools is a prompt injection attack.

• Enterprises need to treat AI Agents as software execution entities with specific identities and permissions, and control risks through least privilege, tool isolation, operation approvals, and auditing mechanisms.

How Are AI Agents Different from Traditional AI Chatbots?

Traditional AI chatbots primarily complete tasks by receiving user input and generating text responses. Even if a model can provide code, analyze files, or explain operational steps, it generally cannot directly modify an enterprise database, deploy an application, or call an internal service without being connected to an actual execution environment.

The difference with AI Agents is that they can connect model-generated decisions to external tools. For example, developers can configure an Agent with code search, terminal execution, database query, and Git repository management tools. When a user submits a task, the Agent can first retrieve relevant files, then call tools to obtain information, and subsequently decide what to do next based on the results. With the appropriate permissions, an Agent may even create code commits, trigger tests, or execute deployment processes.

This model transforms an AI Agent from a simple information-generation tool into a software system with certain operational capabilities. The Agent itself may not have independent administrator privileges, but it can gain the ability to access external systems through user authorization, service accounts, API Tokens, or other identity credentials.

Therefore, AI Agent security cannot be assessed solely by whether the model's responses are accurate. Even if the model-generated content contains no obvious errors, the Agent may still perform operations beyond the user's expectations if its tool permissions are improperly configured. Enterprises need to focus not only on what AI generates, but also on what AI can read, what it can call, and which operations can actually change system state.

How Do AI Agents Call Tools?

Tool calling is an important mechanism through which AI Agents interact with external systems. Developers typically provide the model with the names, functional descriptions, and parameter structures of available tools. The model then determines whether to call a particular tool based on the current task. The actual execution is generally performed by the Agent's runtime environment or application, after which the tool's results are provided to the model for further processing.

For example, an internal enterprise development Agent may be able to read code repositories, query error logs, and run tests. When a user asks it to investigate an issue with a service, the Agent can call a log-query tool to locate the problem, read the relevant code, and then generate modification recommendations. If the enterprise also grants code-writing or deployment permissions, the Agent may move from providing analytical assistance to carrying out actual operations.

The risks of tool calling primarily come from two areas.

• The Agent may receive excessive execution permissions. For example, it may need only to read logs but also have the ability to modify production environment configurations.

• The Agent may process untrusted content from external webpages, code comments, emails, or tool outputs. If the system fails to properly distinguish this content from the user's actual authorization, external information may influence subsequent tool calls.

This means enterprises cannot simply treat model-generated tool calls as trusted operations. Every tool call involving sensitive data or system changes requires independent permission verification. The model can submit an execution request, but whether the request is permitted should be determined by explicit security policies.

Why Can AI Agents Expand an Enterprise's Attack Surface?

Traditional enterprise security systems generally establish access controls around employee identities, servers, applications, and network boundaries. Different employees have different system permissions, while critical services may restrict access through separate credentials and network rules. Once AI Agents connect to enterprise systems, they effectively create new automated access paths.

For example, a development Agent may connect simultaneously to a Git repository, an internal knowledge base, a cloud platform, and a task management system. To complete cross-system tasks, developers may configure multiple API Tokens or service accounts. If these credentials are not strictly restricted, an attacker who gains control of the Agent's runtime environment or related identity may use these access capabilities to reach more systems.

Another issue is operational speed. Employees typically need to log in to multiple platforms manually to complete a series of operations, whereas an AI Agent can call tools continuously within a short period of time. Automation is not inherently insecure. However, without rate limits, anomaly detection, and approval for high-risk operations, erroneous or malicious instructions may be executed quickly.

Therefore, AI Agents expand not only the number of software interfaces, but also the permission relationships connecting different systems. Enterprises need to assess which resources each Agent can access, whether it can cross different security domains, and whether paths exist from low-risk tools into high-risk systems.

Why Can Prompt Injection Affect AI Agent Tool Calls?

Prompt injection refers to an attack in which an attacker places instruction-like content in data that a model may read, attempting to change the task the model is supposed to perform. For ordinary chatbots, such attacks may result in incorrect responses or information disclosure. For AI Agents with tool-calling capabilities, they may also affect actual operations.

For example, an enterprise may use an AI Agent to automatically organize issue reports in a code repository. If an attacker can control the content of a report, they may insert instructions disguised as system maintenance requirements, inducing the Agent to read additional files or call unrelated tools. The real risk is not that the Agent reads the report, but whether it treats untrusted content in the report as an instruction with execution authority.

These attacks are commonly known as indirect prompt injection. An attacker does not need to send commands directly to the Agent's user. Instead, the attacker can influence the Agent through webpages, documents, code comments, search results, or tool outputs. OWASP lists prompt injection, tool abuse, privilege escalation, and sensitive information disclosure as important security risks for AI Agents.

However, prompt injection must be distinguished from traditional malware attacks. If an attacker has already taken control of an engineer's computer through malicious code and then uses existing credentials to access internal systems, the fact that the attack path involved an AI tool does not necessarily mean that prompt injection occurred. The two mechanisms may appear together, but they are technically different.

What Risks to AI Tools and Permission Management Does the Binance Security Incident Reveal?

In its preliminary investigation statement released on November 3, 2026, Binance disclosed a multistage attack that progressed from the compromise of an employee device to the abuse of the internal wallet signing system. According to the statement, in September, attackers induced a software engineer to download a repository containing malicious code through a fake job interview. The malicious code executed during environment configuration and established attacker-controlled communication channels by replacing development tool components and using other methods.

On October 20, the attackers used a compromised engineer's computer and internal AI tools to gain control of additional engineers' devices. They also discovered a container deployment permission Token on the device of a wallet operations engineer. On October 29, the attackers used the relevant credentials to deploy containers and trigger malicious scripts, ultimately reaching the wallet signing operation process.

From a security architecture perspective, this incident reflects at least three issues worthy of study. First, developer devices may become entry points into high-value internal systems. Second, when internal AI tools, deployment environments, and employee permissions are connected, attackers may exploit these connections to expand their access. Finally, if high-risk operations lack sufficient independent permission verification, attackers may convert the internal permissions they obtain into the ability to perform actual asset operations.

It is important to emphasize that Binance has not disclosed the specific implementation of its internal AI tools. Therefore, it is impossible to confirm whether the tools were AI Agents with autonomous planning capabilities, or to conclude that the attack involved MCP, prompt injection, or a vulnerability in a specific model. The incident shows that AI tools may form part of a complex attack path, but it does not by itself prove that an AI Agent was the root cause of the attack.

What Is an AI Agent's Permission Boundary? Why Is Least Privilege So Important?

A permission boundary defines which resources a software entity can access, which operations it can perform, and under what conditions it can obtain additional permissions. For an AI Agent, the permission boundary involves not only the model itself, but also the Agent's runtime environment, tool interfaces, user identity, service accounts, and external systems.

The principle of least privilege requires a system to grant only the permissions necessary to complete the current task. For example, an Agent responsible for analyzing server logs typically needs access only to specific log data. It should not automatically be able to delete databases, modify production environments, or transfer digital assets. If a task genuinely requires a high-risk operation, the Agent should obtain temporary permission through an independent authorization mechanism.

OWASP lists excessive agency as an important risk in large language model applications. The core issue is not that the model has tool-calling capabilities, but that the system has given the model unnecessary functions, excessive permissions, or unconstrained autonomous operating capabilities. When the model is influenced by incorrect input, prompt injection, or malicious tool results, these permissions may increase the potential damage.

Therefore, enterprises need to place permission checks in a trusted execution environment rather than merely telling the Agent through a system prompt not to perform dangerous operations. Even if a model incorrectly requests access to a sensitive tool, the backend service should be able to reject the unauthorized request based on the identity, resource scope, and operation type.

What New Security Challenges Can Tool Connection Protocols Such as MCP Create?

The Model Context Protocol (MCP) is an open protocol for connecting AI applications with external tools and data resources. Through MCP, developers can connect AI Agents to file systems, databases, code repositories, and other services without having to design a completely different integration method for each tool.

This standardized connection method can improve development efficiency, but it also means that Agents may more easily access multiple external systems. If an enterprise does not manage MCP Servers, tool definitions, and access permissions, it may face issues such as excessive tool permissions, malicious tool descriptions, compromised third-party services, or accidental exposure of sensitive information.

For example, a development Agent may need to read a code repository but have no need to access the enterprise payment system. If both types of tools are configured in the same runtime environment and use shared credentials with high-level permissions, an Agent originally intended to assist with development may gain operational capabilities unrelated to its task.

OWASP recommends establishing an auditing mechanism for MCP Servers connected to AI coding tools, restricting the tools that can be called, and checking whether tool definitions contain malicious instructions. Agents that execute code should also use measures such as sandboxing, network access restrictions, and independent credential management.

MCP itself does not constitute a security vulnerability. What needs to be assessed is the tool implementation, authentication, permission configuration, and how external content affects the Agent's behavior after the protocol is connected.

How Should Enterprises Protect AI Agent Identities and Access Permissions?

Enterprises should first establish an identifiable and auditable identity system for AI Agents. Traditional applications typically use service accounts or API Keys to access other systems. However, AI Agent operations may involve user authorization, automated tasks, and multiple tools simultaneously. Enterprises therefore need to clearly distinguish among the user's identity, the Agent's identity, and the actual execution permissions.

For example, an employee asking an Agent to retrieve an internal report does not mean that the Agent can use its service account to read other files that the employee is not authorized to access. A proper authorization design should verify both whether the requesting user is authorized to access the target resource and whether the Agent is permitted to perform the corresponding operation. This helps prevent the Agent from bypassing existing access controls because its proxy service has higher privileges.

In February 2026, the National Cybersecurity Center of Excellence (NCCoE) under the National Institute of Standards and Technology (NIST) published a concept paper on software and AI Agent identity and authorization. The paper discussed issues including Agent identity recognition, authentication, authorization, temporary credentials, delegated permissions, and auditing. This reflects how AI Agent security is expanding from model output controls to a complete identity and access management framework.

In actual deployments, enterprises can use short-lived access credentials and restrict permissions to specific tasks, resources, and time periods. Independent approval and secondary verification should also be required for high-risk activities such as production deployments, financial operations, and permission changes. This way, even if the Agent's runtime environment is compromised, an attacker may not be able to directly obtain long-lived, high-privilege credentials.

How Can Enterprises Reduce the Security Risks of AI Agent Tool Calls?

Enterprises can establish safeguards in four areas: tool permissions, execution environments, sensitive operations, and behavior monitoring.

• Enterprises should restrict the tools an Agent can use based on business requirements. An Agent that only retrieves information does not need arbitrary code execution capabilities, and an Agent used for code review should not automatically receive production deployment permissions. For tools with write capabilities, enterprises can further restrict file paths, database tables, API operation types, and access scopes.

• High-risk tools should run in isolated environments. Code execution, third-party package installation, and external webpage processing may introduce untrusted content. Enterprises can therefore use containers or other sandbox technologies to restrict access to file systems, networks, and system resources. Isolation reduces the likelihood that an attack on a single tool will affect other systems.

• Enterprises should require human approval for irreversible operations. Operations such as deleting important data, modifying permissions, deploying production services, or transferring assets should not be completed automatically merely because the Agent determines that the task is reasonable. Microsoft's Agent Framework security guidance likewise recommends determining whether human confirmation is required based on the impact, data sensitivity, and reversibility of the operation.

• Finally, enterprises need to establish continuous auditing mechanisms that record which tools the Agent used, which resources it accessed, whether abnormal permission requests occurred, and whether the actual execution results matched the authorized task. For repeated failed tool calls, abnormal data access, and large numbers of operations within a short period, enterprises can combine rule-based detection with behavior analysis to identify potential risks.

These measures cannot guarantee the complete elimination of AI Agent security risks. However, they can reduce the scope of impact after a successful attack and increase the likelihood that abnormal behavior will be detected and addressed.

Why Is AI Agent Security Becoming an Important Issue for Web3 Infrastructure?

The combination of AI Agents and blockchain infrastructure gives tool calling and permission management more direct implications for asset security. In traditional enterprise scenarios, an Agent may execute code, send emails, or modify a database. In Web3 scenarios, an Agent may also connect to wallets, query on-chain assets, call smart contracts, or initiate transaction requests.

For example, an Agent used to automatically manage on-chain assets may need to query balances, analyze the market, and provide trading recommendations based on user settings. If it also receives transaction signing or smart contract calling capabilities, enterprises must clearly define which operations can be executed automatically, which require user confirmation, and how to limit the amount per transaction, asset scope, and authorization validity period.

In this process, Session Keys, smart accounts, and granular authorization mechanisms can provide different forms of permission management. However, their specific security depends on how they are implemented. Session Keys can limit certain operational permissions to a specific period or scope, while smart accounts can restrict transaction behavior through contract rules. Nevertheless, security risks may still arise if authorization conditions are too broad, validation logic contains defects, or the execution environment is compromised.

Therefore, the development of Web3 AI Agents cannot focus only on the efficiency of automated trading or on-chain payments. It must also address identity verification, permission delegation, transaction approvals, and authorization revocation. For AI systems connected to real assets, the security boundary should cover the complete process from model decisions to tool calls, transaction construction, signature verification, and on-chain execution.

Conclusion

AI Agents are changing how enterprises use artificial intelligence. As models connect to code repositories, internal APIs, databases, and automation tools, AI systems are no longer merely entry points for information processing. They are increasingly becoming software execution entities with actual operational capabilities.

Binance's preliminary investigation into the security incident disclosed on November 3, 2026, indicates that internal AI tools may have appeared in a complex attack path. However, the available information is insufficient to prove that the incident was directly caused by an AI Agent vulnerability or prompt injection. The more important lesson is that enterprises need to reassess the access relationships among development environments, automation tools, and high-privilege systems.

In the future, AI Agent security will depend not only on whether models can identify malicious instructions, but also on whether enterprises can establish reliable identity authentication, least privilege, tool isolation, and independent approval mechanisms. Only by properly separating AI decision-making capabilities from actual execution permissions can enterprises control potential risks while improving automation efficiency.

FAQ

Why Do AI Agents Have More Security Risks Than Ordinary Chatbots?

AI Agents may access enterprise data, execute code, or modify systems through tool calls. Compared with chatbots that only generate text, their errors or manipulated behavior may have real operational consequences.

What Is AI Agent Tool Calling?

Tool calling refers to an AI Agent requesting that an external program or service perform an operation based on the requirements of a task, such as querying a database, reading a file, calling an API, or running code.

Can Prompt Injection Always Control an AI Agent?

Not necessarily. Whether prompt injection succeeds depends on the system design, model behavior, and security controls. Even if an attacker influences the model's output, independent permission verification can prevent unauthorized tool operations.

Does the Binance Security Incident Prove That AI Agents Have Vulnerabilities?

No. Binance's preliminary investigation confirmed that the attack path involved internal AI tools, but it did not disclose technical evidence sufficient to establish the existence of an AI Agent vulnerability or prompt injection.

Does MCP Increase AI Agent Security Risks?

MCP can help AI applications connect to external tools, but the primary security risks come from tool implementation, access permissions, and the handling of untrusted content. Proper authentication, tool auditing, and permission restrictions can reduce these risks.

How Should Enterprises Restrict AI Agent Permissions?

Enterprises can use least privilege, task-specific temporary credentials, independent operation approvals, sandbox isolation, and tool call auditing to ensure that Agents can perform only explicitly authorized operations.