Your secrets, including especially AI API keys, may be stolen and used to make you pay for the hacker’s compute, some of which is typically used to hack other victims.
Post 7 of a series on AI liability for general counsels interested in the legal liability associated with building and using agents.
Your agent just called a model with a key that was sitting in a config file, a prompt, or a public repo. Or a compromised developer tool grabbed the key and used it. Or an agent with broader access than it needed wrote the key into a log or an artifact another agent could read. The charges start. The data starts moving. The first question is not how the model behaved. The first question is how the key got into a place an agent or an attacker could use it, and whether you can show the path was prohibited.
Model API keys are not ordinary credentials. Once an agent or a compromised tool has them, the key becomes a delegated action path. It can generate runaway spend, pull data, or call downstream systems the original human never intended. In October 2026 the OpenCode Console breach exposed keys for OpenAI, Anthropic, and Google. Also in October 2026 LiteLLM was hacked and information including model keys was exfiltrated. In both cases attackers used them for distillation and hacking and ran up real charges. CERT-In has documented research agents logging into live systems with credentials left in public repos, configuration files, and client-side JavaScript. None of the victims spotted it themselves. The pattern is consistent: the secret was reachable, and someone or their agent used it.
Most companies treat secrets as a developer hygiene problem. Rotate the keys. Scan the repos. Hope the next agent does not write the new key into a context window or a shared store. The policy that was supposed to keep secrets out of prompts, logs, and agent-reachable artifacts lives in one place. The runtime that was supposed to enforce short-lived tokens lives in another. When the bill or the breach notice arrives, the answer is a reconstruction.
Supply-chain risk travels with the same exposure. Agents, tools, skills, and MCP servers are built from packages. If you cannot show what was built, from what, and by whom, you cannot show what was allowed to run or what secrets it was permitted to touch. A signed Software Bill of Materials and provenance attestations are the foundation. Without them the agent image itself is an untracked path for both secrets and code.
The practical requirements are straightforward. You need secrets isolated so keys never reach prompts, logs, or agent-reachable artifacts. You need short-lived credentials that expire. You need spend and action ceilings bound to the same policy that governs the agent. You need data-class rules that treat secrets as a restricted class with copy-out forbidden. You need provenance so you can show the agent and its tools were built from known, signed components. You need the intersection of those ceilings compiled into a signed contract the runtime enforces. You need traces that record credential use, tool calls, and policy decisions against that contract.
At Trustabl we treat secrets and supply-chain exposure as acceptance criteria rather than after-the-fact scanning. Company Policy can require signed artifacts, declare secrets as a restricted class, prohibit copy-out, and bind a budget pack so spend ceilings travel with the agent. The compiler intersects those requirements and produces one signed contract. It generates the corresponding policies for the Policy Enforcement Points so the isolation holds at runtime. The Safe Agent Control Plane records credential-related spans and policy decisions in the same evidence bundle. The open-source Safe Agent Builder tools help teams produce agents that do not embed or exfiltrate secrets in the first place. We do not claim this makes every key unstealable. We claim it makes the prohibited path visible and enforceable, and gives you a record that the path was prohibited when someone asks.
Agents will keep needing credentials to do useful work. The companies that can show the credential was short-lived, isolated, and bound to an enforced ceiling will be in a different position from the companies that discover the key in an attacker’s hands.
Additional reading in this series
Related Blogs
Agent Reliability Resources
