BOSSAI: API access needs authorization and evidence
Agents can expand the reach of an unauthorized query. The BOSSAI case helps define what access your API permits and what evidence supports each conclusion.
Czytaj po portugalskuBy Pentesty
November research with distinct levels of confirmed impact
In its technical research published November 4, 2026, Acronis describes BOSSAI as an operation coordinated by one person, with 12 configured agents and nine active. It separates roughly ten targets with confirmed data extraction or system access across three countries from unsuccessful or unconfirmed attacks and reconnaissance. These are the researchers’ classifications; Pentesty has not investigated the affected systems.
The technical account distinguishes an exposed patient-record platform holding 2018 data from case records extracted through the API of the 119 emergency dispatch service across seven Taipei districts. Exposure alone does not establish that the entire patient dataset was extracted. Dispatch case records also do not represent live ambulance tracking.
Turn the risk into a question about the API
The enterprise question is which operation can reach which data. An internet-facing API can support a legitimate function; publishing it does not authorize access to every person, department or historical record. Inventory individual lookups, searches and exports, identifying the account, business purpose and owner of each returned dataset.
Assess fields and volume too. An account allowed to view a request’s status may not need a complete address, medical history or bulk export. Record the expected policy for each operation and object. The team should be able to explain every available field, including older integrations that continue responding outside the main interface.
Require evidence of both permission and denial
In an authorized lab, prepare two fictional departments, accounts with different roles and identifiable synthetic records. Demonstrate the permitted query first. Then check whether that account can receive data reserved for the other department or perform an unapproved export. Retain the service’s authorization decision and actual result, without testing third parties or using real patient records.
A response code alone leaves questions unanswered. Check whether the body contains data that should have been denied and whether the operation changed any state. Define expected results, repetition limits and stop conditions beforehand. Our assessment of agent destinations and actions complements this exercise by examining the tool’s path to the receiving service.
An agent’s assertion still needs verification
Acronis also reports fabricated or misclassified findings during the operation. When accepting an AI-assisted conclusion, distinguish a suggested discovery, reproduced behavior and demonstrated impact. Keep those distinctions in the report even when the agent’s explanation sounds precise or assigns a high severity rating.
Retain the service version, test identity, authorized operation, timestamp and identifiers connecting the call to the receiving system’s records. Add minimized result evidence and identify the reviewer. Our analysis of AI-assisted finding validation develops this acceptance process. Avoid copying complete responses containing personal information into conversations, reports or tracking systems.
Include handoffs between people, models and tools
In its investigation summary, Acronis describes manual handoffs between agents and commercial models refusing offensive requests. That account does not establish a fully autonomous operation or demonstrate that a model’s refusal will protect another application. Authorization needs to govern the operation reaching the service.
For internal agents, keep credentials limited to the task, approved destinations and an attributable identity for each execution. A recommendation copied from another tool should not expand permissions. In incident response, separating recommendations from execution helps define when human review is necessary and how to stop the workflow.
Accept a bounded result and retain unresolved questions
For each selected scenario, give API, identity and data owners a small matrix: operation, resource, expected permission, observed result and evidence. Record exceptions, the remediation owner and the agreed retest. Repeat legitimate cases after the change to detect unwanted blocking as well as confirm the intended denial.
Approval covers the components and scenarios examined. It does not establish the absence of earlier access or universal protection against AI-assisted attacks. A real incident investigation needs its own records, time window and scope. For business decisions, that boundary is more useful than an agent count or a report that turns attempted targets into victims.
Frequently asked questions
Was BOSSAI a fully autonomous operation?
According to Acronis, the operator manually transferred results between agents. Tasks were automated, but the account does not describe an entire operation without human intervention.
Does a public API authorize access to every record?
Technical availability does not define authorization. The team needs to establish which identities may access which objects, fields and operations, checking the result at the service itself.
Does an AI report establish data extraction?
The assertion needs evidence supporting that outcome. Keep suggested discoveries, reproduced access and confirmed extraction separate, with an identified reviewer and explicit limits.
How can we assess the application without patient data?
Use synthetic accounts, departments and records in an authorized environment. Combine permitted and denied queries and check the receiving system’s records, without involving third-party systems.
Sources and references
- Acronis TRU: BOSSAI technical research, November 4, 2026
- Acronis: investigation summary and limits of automation
Original Pentesty analysis, published November 9, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.