Securing the AI tools that hold your credentials

Somewhere in your setup there is a machine that knows everything. It might be a small server running an automation tool, a laptop with a coding agent on it, or a container someone spun up to test a workflow and never turned off. It holds the API key for the model you call, the token for your email, the connection string for the database with the client list, and the credential your invoicing tool uses. It has that access because collecting it in one place was the only way to make the automation work.

That machine used to be uninteresting to attackers. It ran a niche tool, it was not a bank, and getting from it to anything valuable took a person with time and skill. Both of those things have changed, and the second one changed faster than most small operators noticed. This guide is about what to do with the machine that holds your keys, and it is written for the person who set up the automation and also owns the business. If you have a security team, an asset inventory and a patching rota, you need a longer document than this one, and you probably already have it.

Attackers automated the boring middle of an intrusion

The expensive part of an intrusion was never the first exploit. It was the middle: reading what you landed on, finding the next credential, working out which service it opens, fixing the thing that broke, and doing it again. That part needed a person, and people are the scarce resource in crime as in everything else.

That middle is now largely automated. In November 2025, Anthropic reported disrupting a Chinese state-sponsored group that used Claude Code against roughly 30 targets, and wrote that “the threat actor was able to use AI to perform 80-90% of the campaign, with human intervention required only sporadically (perhaps 4-6 critical decision points per hacking campaign)” [4]. Anthropic said it believes this is “the first documented case of a large-scale cyberattack executed without substantial human intervention” [4]. Three months earlier the same team had described a criminal operation that hit at least 17 organisations across healthcare, emergency services, government and religious institutions, where “Claude Code was used to automate reconnaissance, harvesting victims’ credentials, and penetrating networks” and where “Claude analyzed the exfiltrated financial data to determine appropriate ransom amounts”, which sometimes exceeded 500,000 USD [5].

The speed is the part that should reset your assumptions. In the JADEPUFFER incident Sysdig published in July 2026, an agent inserted a backdoor admin user into a MySQL database at 19:34:24, watched the login fail at 19:34:36, issued a corrected payload at 19:35:07 that imported bcrypt directly instead of shelling out to subprocess.run(...), and logged in successfully at 19:35:18 [1]. The whole notice-diagnose-fix loop ran inside a minute, and nobody was awake for it. There is no window in which you spot a failed attempt and get ahead of the next one, because the next one arrives before you have finished reading the alert.

The key ring is taken before the data

Watch the order of operations in a modern intrusion and the priorities are clear. In the JADEPUFFER chain, the agent entered through an internet-facing Langflow instance, enumerated the host, and swept the environment for secrets: “LLM provider API keys (OpenAI, Anthropic, DeepSeek, Gemini, and others)”, cloud credentials with explicit coverage of the Chinese providers behind the ALIBABA_, ALIYUN_, TENCENT_ and HUAWEI_ variables, database credentials, and “Cryptocurrency wallets and seed phrases” [1]. Only after that did it dump the Postgres database behind Langflow, probe a MinIO object store still running with the default minioadmin:minioadmin login, and move to a separate internet-exposed production server, which it worked on through the Nacos auth-bypass family (CVE-2021-29441) and through that host’s exposed MySQL port using root credentials [1]. It also left a crontab entry beaconing to its own server every 30 minutes [1].

Read that as an inventory problem rather than a hacking story. The reason a small automation host is worth attacking is that it is a key ring, and a key ring is worth more than any single door it opens. Model API keys were among the first things this agent took, well ahead of the database it eventually held to ransom [1]. So the first question to answer about your own setup is not “is it patched” but “if someone read every environment variable and config file on this box, what would they now hold, and what would each of those open”.

Write that list down, because it is the only accurate description of your blast radius, and it is almost always longer than the mental version. Then shorten it in the two cheap ways. Delete credentials the machine no longer uses, which on any host older than six months is usually several. And put a ceiling on the ones that remain. Anthropic’s API tiers carry monthly spend caps of 500 USD on Start, 1,000 USD on Build and 200,000 USD on Scale, and you can “set your own spend limit below your tier’s cap to control costs” [7]. Once you hit the cap, API usage pauses until 00:00 UTC on the first day of the next month, and requests return HTTP 429 with the error code enforced_spend_limit_reached [7]. You can also set custom spend and rate limits per workspace, though not on the default workspace [7]. A key that lives on a machine you do not watch every day belongs in its own workspace with a limit you would not mind paying twice.

Self-hosting an AI tool is a patching commitment

The entry point in JADEPUFFER was CVE-2025-3248, a code injection flaw in the /api/v1/validate/code endpoint of Langflow versions before 1.3.0, where “a remote and unauthenticated attacker can send crafted HTTP requests to execute arbitrary code” [2]. It scores 9.8, it was published on 7 April 2025, and CISA added it to the Known Exploited Vulnerabilities catalog on 5 May 2025 with the ransomware-use field set to Known [2][3]. The fix shipped in Langflow 1.3.0; the victim in the incident Sysdig published in July 2026 was still running something older [1][2].

One CVE is a story about one victim. The catalog is the useful artefact. As of 4 September 2026 it holds 1,695 entries, six of which name Langflow, added on 5 May 2025, 25 March 2026, 21 May 2026, 7 July 2026, 21 July 2026 and 4 August 2026 [3]. That is roughly one confirmed-exploited flaw a month in a single AI orchestration tool since March. Choosing to self-host software in this category means accepting a release cadence you now have to track, not a one-time install.

The deadlines attached to those entries moved too. CVE-2025-3248 was added on 5 May 2025 with a remediation due date of 26 May, three weeks later [3]. The Langflow entry added on 4 August 2026 carries a due date of 7 August, three days later, under CISA’s Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk” [3]. Those deadlines bind federal agencies rather than you, but they are a reasonable read on how quickly the agency thinks exploitation now follows disclosure, and that read is free to copy.

The practical version for a small team is unglamorous. Prefer the vendor’s hosted version of an AI tool unless you have a specific reason to run it yourself, because then patching is someone’s job and that someone is not you. If you do self-host, subscribe to the project’s release feed, put a recurring 30 minutes in the calendar for updates, and do not expose the admin interface to the open internet when a private network or an authenticating proxy would do. Change every default credential on the first day, since minioadmin:minioadmin was a working login on a production object store in 2026 [1].

The entry point does not have to be a vulnerability

Patching closes the door JADEPUFFER used. It does not close the one your own agent opens by reading things. One of the details Sysdig flagged as evidence of an LLM in the loop was that the attacking agent “parsed free-text context presented by the target and took an action that only makes sense if that text was read and understood” [1]. Point that observation the other way around and you have the problem with your own tooling: your agent also reads free text it did not write, in support tickets, scraped pages, invoices, repository files and email.

The clearest framing of the risk is Simon Willison’s lethal trifecta, which is what you get when a system combines access to private data, exposure to untrusted content, and the ability to communicate externally [8]. The underlying reason is that “LLMs follow instructions in content” and models “will happily follow any instructions that make it to the model, whether or not they came from their operator or from some other source” [8]. Willison is sceptical of guardrail products, notes that we still do not know how to prevent this “100% reliably”, and argues the practical defence is to avoid assembling all three capabilities in one system [8].

For an operator, that translates into a design rule rather than a purchase. The agent that reads your inbox should not also hold the credential that moves money, and the workflow that summarises scraped pages should not have write access to your customer database. If a job genuinely needs all three legs, put a human approval step on the leg that acts, and accept that the approval step is the control, not decoration. This is the same least-privilege principle you would apply to any other process, applied to the one process that takes instructions from strangers by design.

Give the agent a smaller room to work in

The tooling for confining agents got considerably better in the last year, and most people have not turned it on. Claude Code ships a sandboxed Bash tool where “you define which files and network domains commands can touch, and the operating system enforces that boundary for every Bash command and its child processes” [6]. It uses the built-in Seatbelt framework on macOS and bubblewrap with a socat relay on Linux and WSL2, and you configure it from the /sandbox panel inside a session or from settings.json [6]. By default, sandboxed commands can write to the working directory, the session temp directory, and any directories you added explicitly [6].

Two settings matter more than the rest for the problem in this guide. The first is sandbox.credentials, which names files and environment variables to protect from sandboxed commands: entries with "mode": "deny" block reads of a path such as ~/.aws/credentials or ~/.ssh and unset variables such as GITHUB_TOKEN before each command runs [6]. A "mask" entry goes further, showing the command a per-session sentinel while the sandbox proxy swaps the real value back in on requests to hosts you list, so “the command and anything it logs never hold the real credential, but its requests still authenticate” [6]. The second is the network allowlist, sandbox.network.allowedDomains, which confines outbound traffic to hosts you name [6]. That one directly removes the exfiltration leg of the trifecta for anything running inside the sandbox.

Read the escape hatches before you rely on any of this. There is no built-in credential deny list, so only the files and variables you list are restricted [6]. Commands that cannot run sandboxed fall back to the normal permission flow, and Claude may retry a blocked command with dangerouslyDisableSandbox, which you can switch off with "allowUnsandboxedCommands": false for what the panel calls Strict sandbox mode [6]. Turning filesystem isolation off while keeping commands auto-allowed is worse than it sounds, and the docs say so plainly: a sandboxed command can then “write files that later commands run or read, such as shell startup files, executables on $PATH, or ~/.claude/settings.json, and use them to widen its own access on the next run” [6]. A sandbox is a boundary, not a verdict on the code inside it.

Paying does not restore anything

The JADEPUFFER agent encrypted 1,342 Nacos configuration items using MySQL’s AES_ENCRYPT() function, which defaults to AES-128-ECB, while the ransom note claimed AES-256 [1]. More important than the mismatch is what happened to the key: it was generated from two base64-encoded UUIDs, printed to stdout, and “never persisted or transmitted” [1]. Sysdig’s conclusion is the one line to carry away from the whole incident. “The victim cannot recover the encrypted configurations even with payment” [1].

That is not a moral argument against paying. It is an operational one. An automated extortion chain can destroy data as a side effect of being automated, without anyone intending an unrecoverable outcome, which means your restore path is the only path you actually control. So the backup test for a small operator is narrow and answerable. Assume the machine that holds your keys is compromised tonight, then check two things: whether the credentials sitting on that machine would let an intruder reach the backups, and whether you have restored from those backups recently enough to know the restore works. A backup your automation host can write to is a backup that gets encrypted alongside everything else.

What still goes wrong

The honest limit is that none of this is new advice. Patch, segment, least privilege, tested backups: the list has barely changed in 20 years, and the reason it goes undone is not ignorance. It is that each item is unbillable work with no visible result, and there are always three billable things in front of it. Automation has not changed the remedy, only the interval you get between exposure and consequence, and an interval measured in days is not one you can cover by being clever later.

The evidence base is also thin in a specific way. Public incident reports come from the vendors whose products were involved or whose telemetry caught it, which means they are selected for being detectable. JADEPUFFER was identifiable partly because the agent annotated its own payloads, and as Sysdig puts it, “Human operators do not annotate disposable python3 -c one-liners this way, but LLM code-generation does so by default” [1]. That is a real detection signal today and a fragile one, because it is a stylistic artefact rather than a structural constraint, and any attacker who reads the writeup can suppress it. Treat published detection signatures as a floor on what is happening rather than a description of it.

And the confinement tooling is young. Sandbox configuration is per-tool, it differs between vendors, and it moves fast enough that individual settings in the Claude Code docs carry their own minimum version numbers [6]. None of it reaches the hosted automation platforms where a lot of small-team credentials sit. There is no product you can buy that answers the question this guide opens with. Somebody has to sit down, list what the machine can read and reach, and cut both lists. That somebody is you, it takes an afternoon, and the afternoon is cheaper before the incident than after it.