AI Workflow Approval Testing: Lessons from Binance.

What has Binance confirmed about the incident?

Evidence checked on 31 October 2026. This article draws on Binance’s two official updates dated 30 October. It is a snapshot of an ongoing investigation, rather than a completed account of the cause.

In its second update, Binance reported that hot wallets were compromised around 20:05 UTC on 29 October, with approximately US$6.3 billion in token assets lost. The company said it had contained affected infrastructure, revoked affected authorisations and paused withdrawals while reviewing systems. It also described a phased restoration subject to security checks.

The initial update suggested a compromised engineer’s laptop allowed access to a service container and unauthorised withdrawal requests. The second update reported additional breach points. Binance said it had found no evidence of leaked wallet private keys and that the investigation remained ongoing.

These statements leave important details unresolved. They do not identify AI as the cause. We should not turn a developing security incident into a claim about an AI failure.

• Binance: initial security incident update — 30 October 2026 ↗
• Binance: Security Incident Update #2 — 30 October 2026 ↗

The business question: what is your automation allowed to do?

Our interpretation for AI adoption is straightforward: test the authority attached to an action, as well as the quality of the answer. An assistant that drafts a recommendation has a different risk profile from one that changes supplier details, sends customer messages or requests payments.

An AI can misunderstand a request. A connected account can also have more access than the task needs. Those are different problems, but either can make a small mistake more consequential. A good validation plan asks what the workflow can change, what limits apply and where those limits are enforced.

The diagram below shows a proposed business control path. It is not a reconstruction of Binance’s systems or the attack.

The root cause is still being investigated. These are the gaps to test

We cannot diagnose Binance’s internal controls from public announcements. For your own AI system, however, several practical questions can be investigated without making assumptions about that incident.

OWASP describes excessive agency as a risk arising from too much functionality, permission or autonomy in an AI application. Its guidance includes limiting tools and access, requiring approval for consequential actions and enforcing authorisation in the connected systems. Those are useful starting points for a scoped review.

• OWASP: LLM06:2025 Excessive Agency — permissions, approvals and monitoring ↗

• Access: can an assistant that only needs to read records also edit or delete them?
• Approval: is permission tied to the exact action, record, amount and recipient, or only to a vague “continue” message?
• Changes after approval: does changing the destination or amount invalidate the earlier approval?
• Repeated attempts: can retrying a request cause a duplicate action or bypass a limit?
• Stopping: does a pause prevent queued work and active connections from taking further action?
• Visibility: can someone establish what was requested, allowed, attempted and actually changed?

A simple example: the invoice is approved, but the bank details changed

Imagine a fictional accounts assistant that reads invoices and prepares payment requests. A person approves an invoice for $1,200 to an existing supplier. Before the request is submitted, a new document supplies different bank details.

A useful test asks whether the workflow notices the change and requires the supplier details to be verified again. The approved amount alone is insufficient: the destination has changed. The connected service should enforce the agreed rule, even if the AI says the request is ready.

In a safe test environment, include an unchanged approved request as well. The aim is to show that valid work can proceed while a changed destination is held. Use fictional records and a simulated payment service; no real money needs to move.

This is a proposed test scenario, not an executed VisiFlo assessment, customer incident or explanation of the Binance breach.

Can you stop the action, or only stop the conversation?

A stop button needs a defined meaning. In your own workflow, does it pause new requests, cancel queued jobs, restrict the connected account, or all three? Check the actual behaviour rather than assuming a quiet chat window means every action has stopped.

Practise this with a harmless queued task. Pause the workflow, try the task through the supported connection and inspect the final record. If stopping one part leaves another part active, record the gap and agree how it should be handled.

Also distinguish prevention from repair. Revoking access can prevent later actions; it does not undo a message already sent or a record already changed. Recovery needs a record of those effects and an agreed way to reconcile them.

What a useful VisiFlo review could cover

VisiFlo’s role is to turn broad reassurance into checks a business can understand and review. Start with one workflow, one consequential action and the conditions under which it should be allowed.

This can apply to n8n automations, custom agents, chatbots with tools, API integrations and other connected AI systems. The checks depend on access to the application and the services it uses. Where a boundary cannot be observed, the report should say so.

1. 1. Map the action

   List what the AI reads, which account each connection uses and what it can change. Identify the person responsible for approving consequential actions.

2. 2. Agree the limits

   Define permitted records, recipients, amounts and conditions. Decide what must happen when information changes or approval is missing.

3. 3. Test the exceptions

   Use authorised test accounts and fictional records to check missing approval, changed details, duplicate requests, unavailable services and withdrawn access.

4. 4. Verify the fix and restart

   Compare expected and observed results, prioritise gaps, then retest failures and normal work after changes. Record the evidence behind any decision to resume.

The evidence should be easier to understand than the incident

A report should answer plain questions: what should have happened, what actually happened, what was blocked and what still needs attention? For the invoice scenario, show the approved supplier details, the later change, the expected hold and the observed result.

Include the tested version, conditions, number of attempts and any limits on observation. A blocked request without a check of the final record may leave uncertainty. A successful check under one setup cannot guarantee every future outcome.

For consequential workflows, retest the relevant cases when permissions, business rules, connected services or the model change. Agree who can pause the workflow and who can authorise its return to service.

Where VisiFlo fits alongside security specialists

VisiFlo can help validate business behaviour, identify workflow gaps, explain the evidence and recommend improvements. Remediation and repeat testing can then be scoped with the people who own the systems.

A financial exchange breach also requires specialist incident response, infrastructure security and, where relevant, blockchain investigation. Workflow validation complements that work. It is not a substitute for it, and VisiFlo has not assessed Binance or reproduced this attack.

For businesses adopting AI, the useful next step is concrete: choose one action that matters and establish whether the system can perform it only under the conditions you intended.