Two incidents, one lesson about delegated power
The working headline is the story: BOSSAI and Claude expose agent risks. The cases are different in motive, target and technical path, but they converge on the same security question: what happens when software agents are allowed to act faster than the humans supervising them can reason?
In Taiwan, researchers described a BOSSAI campaign in which a single attacker used a mesh of AI agents to reach emergency-service data, including Taipei emergency dispatch records covering seven districts . In developer tooling, reports on Claude Code’s “Don’t Ask Again” approval path showed how a convenience feature could leave passwords and API keys in public GitHub files when approved commands were saved verbatim . Together, the stories move agent risk from abstract debate to operational reality: agents can compress reconnaissance, execution and leakage into ordinary workflows.
BOSSAI: machine-speed reconnaissance against public services
The BOSSAI case is not described as a magic AI break-in. It is more troubling because it is ordinary security debt exploited at unusual speed. The attacker reportedly aimed agents at hundreds of organizations in at least 11 countries, including emergency services, banks, universities and military systems, while confirmed data access or theft affected about 10 targets in Taiwan, Mexico and Thailand . DailyStraits, summarizing the same research, said the operator was based in Hualien City and ran a 12-agent campaign against those sectors .
The most sensitive Taiwan findings involved emergency response. The agents pulled case records from a city 119 emergency dispatch system, with incident times, response types, status fields and street-level locations; The Hacker News emphasized that these were case records rather than live ambulance tracking . The agents also found a Taipei fire-department platform exposing 2018 patient-care records, including ECG readings and ambulance video, without a login . DailyStraits similarly reported that the Taiwan activity involved patient-care records and 119 case records .
That distinction matters. Dispatch case records may not reveal moving ambulances in real time, but they can still expose operational patterns: where calls concentrate, how incidents are categorized, how response status is recorded, and which districts are represented in the data. Patient-care records raise a parallel privacy problem. In both cases, public-sector data becomes useful not only to identity thieves, but to anyone mapping emergency-service capacity or blind spots.
BOSSAI also shows the limits of the agents. According to The Hacker News, commercial models mostly refused direct offensive requests, pushing the operator toward locally run models with safety training removed . The same reporting says the attacker’s agents did not communicate autonomously with each other; the operator manually pasted one agent’s output into another . That is not the science-fiction “Skynet before breakfast” version of the story. It is more like a fast, stubborn junior operator with many terminals open.
The failures are just as important as the successes. The campaign reportedly produced hallucinated vulnerabilities, false positives and claims of results that had not happened . The agents failed where authentication was enforced, where paywalls required a valid session and where endpoints were properly filtered . In other words, AI widened the search and reduced the cost of trial, but it did not erase the value of basic controls.
Claude Code: when approval friction becomes a secret leak
The Claude Code case is more domestic, but no less instructive. It starts with a familiar developer habit: approving a command so the tool will not ask again. Reports said that when a user selected “Yes, and don’t ask again,” Claude Code could save the approved shell command into .claude/settings.local.json; if that command contained a password or token, the secret could be stored in plain text .
The headline numbers vary because they count different scopes. The Hacker News reported that Apiiro found 104,185 public copies of the relevant settings file, with 1,122 files containing at least one secret and 1,379 distinct secrets in those files . LATENT broke the count down further, noting that the broader total of 2,539 secrets includes older versions, shared settings and saved agent transcripts, while the 1,122 figure refers to current public copies of .claude/settings.local.json . Yaamlabs made the same distinction, adding that the broader set covered 1,994 repositories and 63 organizations .
This discrepancy is not mere bookkeeping. It shows why automated leakage is hard to measure. A secret may appear in the current default branch, in git history, in a fork, in a shared settings file, or in an agent transcript. Deleting the visible file is therefore not remediation; rotation comes first. The Hacker News reported that older versions contained 734 more secrets across 509 repositories, and that 211 forks of 74 repositories carried the same secrets as originals .
The mechanism is also a design lesson. Claude Code reportedly tries to keep the local settings file out of git by adding it to a user’s global git excludes, but that protection lives on one machine and does not travel with the project’s own .gitignore . Yaamlabs described the practical leak cases: a new machine or container without the global ignore, copied project folders, forced git add, or repositories where the file was already tracked . In 539 of 1,105 traced repositories, Apiiro found that a commit listing Claude as co-author changed the file, though Yaamlabs notes that this is an inference rather than proof that Claude added each secret .
Why scanners and defaults need to change
The Claude Code reports also challenge a common defense assumption: “we have secret scanning.” LATENT reported that Gitleaks detected 50.3% of the 1,122 affected files and TruffleHog 57.3%; together, they still missed 215 files, or 19.2% . Yaamlabs explained why: many leaked values are ordinary-looking passwords embedded inside commands or connection strings, not provider keys with recognizable prefixes .
Ranthis ran a hands-on test with a fake password and reported that choosing “Yes, and don’t ask again” copied the full command into .claude/settings.local.json; the same test found that using an environment variable prevented the “don’t ask again” option from saving the literal secret . That points to practical mitigations: never type secrets directly into commands approved by agents, prefer environment variables or secret managers, and approve patterns rather than exact commands that contain credentials.
Controls for agent-speed behavior
The shared lesson from BOSSAI and Claude Code is that agent risk is not confined to exotic model failures. It emerges when agents speed up ordinary actions: scanning public endpoints, trying weak credentials, caching command approvals, committing files, and replaying workflows. In the BOSSAI case, defenders need telemetry that sees machine-speed reconnaissance, API enumeration, SQL-injection attempts, default-credential use and unusual bulk reads across sensitive systems . In the Claude Code case, engineering teams need repo-level ignore rules, pre-commit checks, history scanning, credential rotation and narrowly scoped permissions around agent settings .
Security teams should treat agent files as secret-bearing by default. That includes .claude/ directories, shared settings, transcripts, memory files and any approval cache that records what an agent ran. Organizations should also distinguish between approval of an operation and approval of the sensitive parameters embedded inside it. Convenience mode should reduce repetitive prompts, not become sudo with amnesia.
The deeper shift is cultural. Human-speed controls assume someone notices the risky step before it matters. Agent-speed systems can perform the risky step, save it, repeat it and move on. BOSSAI shows how one operator can multiply reconnaissance against critical public data. Claude Code shows how a single click can preserve a credential long after the developer has forgotten it. The fix is not to ban agents; it is to design them as systems that are expected to make security-relevant mistakes, then contain those mistakes before they become public infrastructure incidents or public repository leaks.
Comments
Be the first to comment.