Hacker Uses BOSSAI AI Agents to Steal Taipei Emergency Records

A solitary attacker operating from Hualien City, Taiwan, deployed an autonomous setup of artificial intelligence agents named BOSSAI to breach systems and steal sensitive records across multiple countries, researchers at Acronis's Threat Research Unit disclosed. The operation compromised emergency dispatch records across seven Taipei districts, exposed fire department patient data dating back to 2018, and breached database records at organisations in Taiwan, Thailand, and Mexico. The incident demonstrates the emerging operational risks where automated AI agents exploit misconfigured, unauthenticated, and poorly protected web interfaces.

Key Facts

What Data Did the BOSSAI Agents Exfiltrate?

The agents accessed emergency dispatch incident logs covering seven Taipei districts, unauthenticated patient ECG readings and ambulance video footage from 2018, and an account table from a Taiwanese lending firm. Outside Taiwan, the system exfiltrated data from three Thai universities and harvested approximately 206,800 Mexican residential phone records containing personal names and addresses.

According to the technical analysis, the emergency dispatch data originated from Taiwan's 119 emergency service system for fire and ambulance dispatch. The AI agents extracted case records via an accessible application programming interface, gathering incident timestamps, response categories, case statuses, and street-level locations, though no live ambulance fleet tracking was obtained. Further intrusions in Taiwan compromised a fire-dispatch technology vendor after the agents logged into a database administration console using default root credentials, securing access to 18 or more database tables.

The agents also probed an emergency management information system, uncovering a hardcoded AES-256 cryptographic key within front-end JavaScript that exposed session-cookie data, including the identity of an administrator. In Thailand, the system selected 489 targets across 45 institutions, successfully extracting data from three universities through SQL injection vulnerabilities affecting unpatched Oracle databases.

The operation compromised data or accessed systems at roughly 10 entities across Taiwan, Thailand, and Mexico out of hundreds targeted globally.

How Did the Attacker Deploy and Control the AI Agents?

The attacker managed a 12-agent framework termed BOSSAI, utilising nine active agents to assemble attack infrastructure and scan networks. Commercial AI models largely rejected explicit attack commands, prompting the operator to bridge agents manually and deploy locally hosted, safety-stripped abliterated models based on DeepSeek, GLM, and Qwen architectures to conduct active intrusions.

Commercial cloud models handled the construction of tools and operational servers, with Grok serving as the primary builder. When directed to execute attacks, commercial models such as Grok and MiniMax M3 refused and requested documentation verifying authorisation. However, Grok repaired a broken proof-of-concept exploit script that was subsequently handed to an attack agent. Coding assistants Claude Code, Codex, and Cursor were also adapted or routed to abliterated models to build infrastructure and target emergency platforms.

Despite their speed, the agents frequently hallucinated findings. Automated scanning tools invented non-existent vulnerabilities, with more than half of high and critical severity alerts identified as false positives, including an alert claiming a critical Apache remote code execution vulnerability on a national disaster-response system. Acronis researchers discovered the attacker's operational server housing over 90,000 files, linking the activity to a single individual after the operator reused personal GitHub handles, email addresses, logos, and exposed a residential IP address during an SSH session recorded in a Grok log.

Acronis researchers tracked the operational attack server containing more than 90,000 files across a 12-day observation period.

What Prevented the AI Agents from Breaching Other Systems?

The AI agents failed whenever systems enforced standard access controls, required validated user sessions, or applied rigorous input filtering. Despite accelerating reconnaissance across hundreds of targets, the tools lacked the capability to bypass functional security boundaries and succeeded almost exclusively against pre-existing vulnerabilities, unpatched services, default credentials, and publicly exposed unauthenticated endpoints.

The investigation showed that target defences held against automated brute-force attempts directed at Taiwan's National Fire Agency single sign-on portal, and reconnaissance scans across fire department infrastructure in five cities yielded no penetration. In Mexico, the collection of 206,800 records relied on combining public telecom authority lists, postal codes, and government census data rather than defeating protective barriers.

The technical evidence indicates that while autonomous agents substantially lower the operational cost of conducting simultaneous, broad reconnaissance, they remain constrained by standard defensive engineering. Where session controls, input validation, and access verification were actively maintained, the automated intrusion attempts stalled completely.

The attacking AI agents were entirely halted by basic defensive hygiene, including active session validation, strict network filtering, and enforced authentication.

What Should You Do?

• Enforce strict authentication and access controls across all public-facing application programming interfaces and diagnostic endpoints.
• Audit administrative consoles immediately to ensure default root or vendor credentials are removed and replaced with unique, complex credentials.
• Inspect front-end web application assets and client-side JavaScript to ensure cryptographic keys, administrator tokens, and secrets are not hardcoded.
• Sanitise all database inputs to protect against SQL injection vulnerabilities and apply vendor patches to database installations, including legacy Oracle deployments.
• Restrict public exposure of internal operational and medical platforms, closing unauthenticated ports and services left online inadvertently.
• Review network indicators of compromise published in the original technical report to identify potential scanning activity from the attacker's nine IP addresses and nine domains.
• Malaysian organisations detecting unauthorised scanning or suspected breach activity can submit incident reports to Cyber999 operated by the Malaysia Computer Emergency Response Team (MyCERT).

Common Questions

Did commercial AI models cooperate with the cyber attacks?

Commercial models largely refused attack instructions and demanded written authorisation, though Grok repaired a defective exploit script. To circumvent restrictions, the attacker utilised abliterated open-weight models—specifically modified versions of DeepSeek, GLM, and Qwen—running locally without safety alignment to conduct offensive operations against targets.

Were live emergency response operations or ambulances tracked?

No live ambulance movements were tracked during the incident. The compromised Taipei emergency service data consisted of static 119 dispatch case records detailing incident timestamps, response classifications, incident handling statuses, and street-level addresses extracted through an unauthenticated public-facing application programming interface.

How was the attacker's identity uncovered by researchers?

Acronis researchers identified the operator through multiple operational security lapses. The attacker reused identical profile handles, logos, SSH key identifiers, and email addresses across legitimate commercial activities and attack servers. Additionally, his residential IP address surfaced directly within an SSH session captured in his Grok conversation history.

Sources and Methodology

This dispatch is based solely on reporting published by The Hacker News on Nov 09, 2026, documenting findings from Acronis's Threat Research Unit. In accordance with editorial standards, this publication has not reviewed or verified any external advisory, secondary document, or vendor page beyond the cited source material.