Six months ago, I installed OpenClaw and connected OpenRouter so the agent could work. By the next day, it had used up the limit I had set. I raised it. I assumed the agent was just expensive to run. Four days later, I looked through the requests. There were lots of requests in Chinese that I hadn’t sent and that had nothing to do with my tasks. Someone was using my API key at my expense. I lost about $100 over a few days. I never established exactly how the key leaked. It might have been prompt injection, a bug in the agent runtime, or another route. The real key was accessible to the agent. Now someone else was using it too. In a typical installation, an agent runs as a process with a particular user’s permissions. Keys for programmatic access to services often live in configuration files or environment variables. If the process can access that file or environment, the agent can read the key, including by running a short script. Reading it requires no special vulnerability. A sandbox creates an awkward trap. I can isolate the agent, but I still want it to do useful work through different services’ APIs. If I put a real key inside the sandbox for that purpose, it is within the agent’s reach again. It can leak through command output or file contents. I can keep the key outside and give the agent access through a separate, isolated tool. But writing a wrapper for every new service, maintaining it and checking the access boundary gets old quickly. I want to connect the services I need to one ready-made solution without assembling new security plumbing for every small task. I had a hard spending limit. I raised it myself because I mistook someone else’s spending for my own agent’s work. The hard limit capped the amount; it didn’t tell me who was spending the money. Providers don’t all offer the same per-key spending controls. Perplexity’s API, for example, has no per-key hard spending cap. In a reply on its official forum on July 10, 2026, the team explicitly stated that the API had no spending caps. Purchased credits and request-rate limits do not replace a separate money budget for each agent. After losing that $100, I no longer want agents to be able to read real keys. Even when the key supports a hard spending limit. I work on open source projects and use coding agents. They have their own machines because I don’t want them taking something from my laptop as well. But they still need access to working services. When an agent sends code or other material to GitHub, I don’t want to wonder whether a key from a configuration file or session history went with it. My case cost roughly a hundred dollars. I looked at how similar situations had ended for other people. One reached the point of production resources being destroyed in AWS. From one GitHub token to a wrecked production environment In its Cloud Threat Horizons report for the first half of 2026, Google and Mandiant describe a breach they investigated in 2025. A malicious npm package stole a developer’s GitHub token. The attackers used the connection between GitHub and AWS to get into the cloud, then created an administrator role for themselves. The whole chain took less than 72 hours. They then stole files from S3 and destroyed resources in the client’s production cloud environment. The token alone was not enough. The attack also relied on excessive permissions and overly broad trust between systems. That is why this case matters to me. A key taken from a development environment opened a door into a system where other configuration mistakes were waiting. In the wider s1ngularity campaign, GitGuardian researchers observed stolen tokens being used to make 10,767 private repositories public . Those repositories contained more secrets. The leak kept spreading into other people’s infrastructure. You can revoke the token and make the repository private again. None of that deletes the code someone has already downloaded to their own disk. This was a dependency attack rather than an accidental agent commit. But code an agent runs gets the permissions of the user running it. If that user can read a real token, a malicious package has something worth taking. At METR, the attacker asked the agent for its key This case connects directly to autonomous agents. On August 31, 2026, research organisation METR disclosed an incident from March . A researcher was running agents on a personal EC2 instance. The dashboard was accessible over the internet and was supposed to require Google authentication. A bug in the application silently disabled authentication. An attacker found the dashboard and asked the agent to reveal its model provider’s API key. With that key, the attacker spent three weeks consuming someone else’s credits, worth roughly $600,000. METR had received those credits for free. There was no $600,000 charge to its bank account. But the unauthorised usage was real, and it went unnoticed among large research runs. The report also describes an SSH key the attacke...