An engineer completed an assignment for an external company’s job interview on a work computer, assuming they were simply configuring a development environment. Unbeknownst to the engineer, malware had already replaced the pyenv executable. Several weeks later, the attackers began using the compromised computer and leveraged the company’s internal AI tools to control other engineers’ computers, ultimately obtaining a container deployment token. In addition to asking, “Is this AI Agent effective?”, managers must now go a step further and ask: “If an account or endpoint is compromised, which systems could an attacker access through the AI Agent?”
This type of attack is known as lateral movement: an attacker first compromises an account or endpoint, then exploits its existing permissions, connections, and trust relationships to expand the attack to other people or systems. We believe that when deploying an AI Agent, companies should first restrict the data it can access, the services it can connect to, and the actions it can perform. Its scope of work should be expanded gradually only after these controls have been validated. If all permissions, connections, and actions are enabled from the outset and reviewed only after an incident occurs, the compromise of a single endpoint could affect many more systems.
An AI Agent Can Get Work Done—but It Can Also Help Attackers Access More Systems
According to iThome’s coverage of Binance’s preliminary public investigation, hackers first compromised a wallet engineer’s work computer through tampered development tools and a fraudulent job interview. On October 20, they used the compromised computer and internal AI tools to take control of two other wallet engineers’ computers, where they found a token with container deployment privileges. On October 30, the hackers used the stolen credentials to deploy containers and run malicious scripts. They then breached the wallet signing service and ultimately transferred approximately US$6.34 billion in crypto assets from hot wallets across multiple blockchains.
The preliminary investigation does not provide every technical detail, so it would be inappropriate to assume that the AI Agent autonomously completed every step. However, the incident highlights a clear management issue: if an internal AI tool can connect to other engineers’ computers, obtain deployment credentials, or invoke privileged services, an attacker who compromises a single user account may be able to exploit that user’s existing connections and permissions to access other systems. In a typical Taiwanese enterprise, for example, an AI Agent that helps sales personnel prepare quotations does not also need access to confidential procurement prices, permission to modify customer master data, or deployment privileges for the production environment.
Companies should therefore inventory who uses each AI Agent, which department it belongs to, what data it can access, which services it can invoke, and which actions it can perform. Detection measures should then be strengthened based on the results. During this review, ask directly: “If this permission were compromised, where could the attacker go next?” Any cross-departmental access that cannot be tied to a clear business need should be removed. Privileged tasks such as deployments, permission changes, and external data transfers should be assigned to dedicated roles and require approval from designated personnel before execution.
Keep Permissions and Connections Disabled by Default, Enabling Them Only When Required
Access control can follow the principle of least privilege, meaning that each user and AI Agent receives only the permissions required to complete the task at hand. Companies need to examine two layers separately: which functions a user can access after signing in, and which resources an AI Agent can actually read or modify when invoking tools on the user’s behalf. If the shared permission scope is too broad, back-end operations may exceed actual business requirements even when front-end roles have been differentiated.
EgentWrX configures front-end and back-end permissions separately. Companies can define built-in or custom roles based on their organizational hierarchy and restrict personnel in each department to viewing only their own department and its subdepartments. This design separates general usage rights from back-end administrative privileges. However, assigning role names alone does not reduce risk. The deployment team must still verify, role by role, which data can be accessed and which actions can be performed. Privileged access should not be retained indefinitely merely for administrative convenience.
Connections should be governed in the same way. Companies should list the external domains, internal databases, and tool services that an AI Agent needs to connect to, deny all connections by default, and enable them individually according to business requirements. In EgentWrX, for example, the egress allowlist denies everything by default, and each external domain must be explicitly permitted. Companies can also allow an AI Agent to access internal databases through the corporate network, with database integrations restricted to read-only access. These mechanisms reduce the data an AI Agent can reach and the resources it can modify, but they do not eliminate the need for endpoint protection, credential rotation, and controls over the provenance of development tools.
When evaluating a system, companies should not ask only whether it supports integration. They should also require the system owner to provide a connection inventory, a permissions matrix, and an approval workflow for privileged operations. Start with a clearly scoped task, such as allowing customer service staff to check order status or quality assurance personnel to read inspection standards. After confirming that read-only access is sufficient to complete the task, the company can decide whether to enable additional actions.
Even If Endpoint Protection Raises No Alert, You Still Need a Record of Every AI Agent Action
Binance stated that its endpoint protection software did not detect the malware at the time and that the attackers also concealed evidence of the intrusion. Although the company had previously replaced the affected devices and reset the relevant credentials, information about the engineers’ roles and colleagues had already been exposed. Following the incident, Binance rebuilt the affected wallet systems and internal AI tools, disabled the relevant credentials, and said it would invite an independent cybersecurity firm to conduct a review. This shows that endpoint alerts are only one source of evidence in an investigation. A lack of alerts does not mean that an AI Agent has not been misused.
Companies need to maintain a separate audit trail for AI Agent activity. At a minimum, they should be able to determine who changed a role and when, which connection was enabled, which privileged tools were invoked, and who downloaded audit records. EgentWrX audit logs cover 55 resource types and can be exported from the Export Center. A hash chain can be used to verify whether records have been altered, and administrators’ audit-log downloads are themselves logged. These records can help companies investigate incidents and produce evidence, but they cannot guarantee that every attack will be prevented.
AI Agent logs should be formally incorporated into the company’s cybersecurity incident response process. During normal operations, records should be exported regularly and checked for completeness. After an incident, endpoint, identity, connection, and AI Agent activity logs should be aligned on a single timeline for comparison. If endpoint anomalies are discovered, the company should do more than replace the computer and reset credentials. It should also review any colleague information the attacker may have accessed, role changes, existing job schedules, and external connections to ensure that no access paths remain available for future exploitation.
Companies can begin with a tabletop exercise: if an engineer’s account were compromised, could the cybersecurity team identify every affected AI Agent, credential, computer, and service that same day? If any item cannot be identified, the related management controls still need to be strengthened.
FAQ
Does the company need to disable every AI Agent because of this incident?
There is no need to disable them all. However, the company should first shut down any cross-departmental access, privileged operations, and external connections that cannot be justified by a clear business need. It should then revalidate clearly scoped, read-only use cases. Access can be restored gradually after confirming that roles, approvers, and logs all align with actual workflows.
Can an AI Agent simply inherit all of a user’s existing account permissions?
It is not advisable to grant an AI Agent all of the user’s permissions. The fact that a user can view certain data does not mean the AI Agent needs that data for every task. Companies should separately inventory the scope of tool invocations and data access, remove unnecessary permissions, and assign operations such as deployments and permission changes to dedicated roles.
Is making the internal database read-only enough to prevent lateral movement?
No. Read-only access reduces the risk of data being modified, but an attacker may still obtain sensitive information or pivot to another service with write access. Companies must also restrict the hosts and external domains that an AI Agent can connect to, narrow the scope and validity of credentials, and retain a record of every invocation.
What information should AI Agent audit logs record at a minimum?
At a minimum, they should record authenticated identities, role changes, connection settings, tool invocations, privileged operations, approval results, and log-download activity. The records must also be exportable and verifiable for completeness so that the cybersecurity team can align AI Agent activity with events from endpoint and identity systems on a single investigative timeline.
References
- Binance Discloses Attack Chain Behind US$6.3 Billion Theft as Hackers Used Fake Interviews to Trick Engineers into Running Malware — iThome’s summary of Binance’s preliminary public investigation, the attack chain, and the company’s incident response.
