Paper: API secrets should never enter an LLM agent's context (arXiv 2609.33371)

What happened on 2026-09-27

At 08:55 UTC on 2026-09-27, Patrick Kenney and co-authors submitted v1 of arXiv 2609.33371, with cs.CR as the primary category. The paper argues that for tool-using LLM agents, key handling is an execution-security problem, not only a storage problem. A key placed in a prompt, a system prompt or a tool configuration can leak into conversation history, logs, memory, generated code and error messages, and prompt injection or excessive agency can turn that passive exposure into unauthorized actions. The authors propose an architecture in which the model only selects a connector identifier and a trusted request boundary attaches the credentials. They ran two controlled black-box experiments on a production implementation, with 16 probes across seven control domains, and every probe gave the expected result. They also report a negative result: one connector's stored header mapping did not meet its provider's authentication requirements. The authors stress that this was a small, purposive functional evaluation, not a certification.

What it means for apps adding AI features

Many independent developers adding AI features call the model provider's API directly from the client. For that pattern the conclusion was clear before this paper: a key shipped with the client can be pulled out of the installed package, and obfuscation only delays that; it does not keep the key secret. The paper adds the server-side picture. Even a key kept on the server can leak through logs, generated content or injected instructions once it enters context the model can see. Its proposal is to let the model only choose which connection to use, never seeing or holding the credential itself. The negative result is just as useful. Central custody of credentials does not guarantee correct configuration. The authors state plainly that it is necessary but not sufficient, and that least privilege, deterministic action authorization, human approval, telemetry redaction and credential rotation are still required.

Checks you can put in place

First, inspect your client packages and front-end output to confirm they contain no model-provider API keys. If any are present, route calls through your own server-side proxy with per-user authentication and quotas. Second, review server code to confirm keys never appear in prompts, system prompts, tool descriptions or any configuration the model can read. Third, redact request and response logs so authentication headers are never recorded. Fourth, give each connection its own least-privilege credential, and set up regular rotation plus a revocation procedure for when a key leaks. Finally, if your app lets users bring their own keys, treat those keys the same way: keep them out of logs and out of anything the model can read.

Your checklist

• Confirm no model-provider keys ship in client or front-end artifacts
• Keep keys out of prompts, tool descriptions and model-readable config
• Redact auth headers in logs and set up key rotation and revocation