Forscher extrahieren echte API-Keys aus LLM-Ausgaben
Allein über den API-Output gelang es, DeepSeek- und Google-Keys aus Modellen wie Qwen3-27B, GPT-Codex 5.3 und Claude Haiku 4.5 zu rekonstruieren. Jeder gefundene Key ließ sich öffentlich auf GitHub nachweisen.
Veröffentlicht am 21. Oktober • Zuerst erschienen auf blog.gitguardian.com
Immer mehr Teams setzen KI-Agenten ein und können damit neue Tools, Apps und Software mit nie dagewesenem Tempo erstellen. Im Kern jeder Verbindung, die diese Anwendungen benötigen, steht ein Credential, häufig in Form eines API-Schlüssels.
Diese Schlüssel werden jedes Mal offengelegt, wenn sie vom KI-System berührt werden, und zwar auf Wegen, die auf den ersten Blick möglicherweise nicht erkennbar sind.
Ein Coding-Agent kann eine lokale Konfigurationsdatei lesen, einen Befehl ausführen oder einen Model Context Protocol (MCP) Server aufrufen. Jede dieser Aktionen kann dazu führen, dass ein Credential in den Kontext gelangt, der an ein Large Language Model (LLM) gesendet wird.
Aktuelle Forschung zeigt, dass offengelegte Credentials auch deutlich weiter flussabwärts überleben können. Die Forscher hinter "Practical Secrets Extraction against Black-box LLMs" konnten Zeichenketten, die echten API-Schlüsseln entsprachen, aus Qwen3-27B, GPT-Codex 5.3 und Claude Haiku 4.5 extrahieren, und zwar ausschließlich über den Zugriff auf die Ausgaben.
Besonders wichtig: Sie hatten keinen Zugriff auf Modellgewichte oder Token-Wahrscheinlichkeiten. Dies geschah vollständig über einen sogenannten "API output-only access", also einen ausschließlichen Zugriff auf die API-Ausgaben.
Das Lecken von LLM-API-Schlüsseln erstreckt sich nun über den gesamten Lebenszyklus von Credentials. Bestehende Credentials sind inzwischen Teil von Trainingsdaten und können in Modellausgaben auftauchen, was tatsächlich vorkommt. KI-Agenten können zudem frische Credentials während der normalen Entwicklungsarbeit in den Modellkontext befördern.
Die Forscher konnten echte Credential-Zeichenketten aus drei Black-box-LLMs extrahieren. Alle drei Modelle gaben ein Geheimnis preis.
Qwen3-27B lieferte zwei DeepSeek-Schlüssel und einen Google-Schlüssel. GPT-Codex 5.3 gab einen DeepSeek-Schlüssel zurück. Claude Haiku 4.5 lieferte zwei DeepSeek-Schlüssel.
Anschließend suchten die Forscher auf GitHub nach jedem vollständigen Credential und fanden jedes Mal eine öffentliche Übereinstimmung. Das stützt die Schlussfolgerung, dass die Modelle echte geleakte Geheimnisse reproduziert haben und nicht bloß Zeichenketten erzeugt haben, die nur gültig aussahen.
Die Forscher machten an dieser Stelle Halt. Sie maskierten die Credentials und prüften nicht, ob die Schlüssel noch funktionierten.
Ein Angreifer oder bösartiger Agent hätte keinen Grund anzuhalten. Ein wiederhergestellter Schlüssel könnte getestet, für den Zugriff auf nachgelagerte Systeme verwendet oder bis zu seiner Sperrung missbraucht werden, wie wir es aus vielen Angriffsszenarien kennen.
Was uns an dieser Arbeit aufgefallen ist: Allein ein Black-box-Lesezugriff kann ausreichen, um gespeicherte Credentials aus Modellausgaben wiederherzustellen. Die naheliegende nächste Frage lautet: Wie sind diese Schlüssel dorthin gelangt?
LLMs können API-Schlüssel in öffentlichen Trainingsdaten finden, und wir wissen, dass es dort sehr viele gibt. KI-Agenten schaffen jedoch eine unmittelbarere Quelle: den Entwickler-Laptop.
Öffentliche Repositories können Teil von Datensätzen werden, die zum Trainieren oder Evaluieren von Modellen verwendet werden. Sobald ein Credential in öffentlichem Code auftaucht, kann es sich auch über Forks, kopierte Beispiele, Logs und andere Entwicklungsartefakte verbreiten. Das geschieht häufig.
GitGuardian hat 2025 insgesamt 28,65 Millionen neue hartcodierte Geheimnisse in öffentlichen GitHub-Commits erkannt. Credentials im Zusammenhang mit KI-Diensten erreichten 1.275.105, ein Anstieg von 81 Prozent im Jahresvergleich.
Die Black-box-Forschung zu LLMs zeigt das Ergebnis dieser Kette. Forscher konnten Credential-Zeichenketten aus eingesetzten Modellen extrahieren und fanden für jeden wiederhergestellten Schlüssel entsprechende öffentliche Vorkommen auf GitHub.
Entwickler-Laptops sind still und leise zu Credential-Speichern geworden. Geheimnisse liegen in.env-Dateien, Cloud-Konfigurationsdateien und der Shell-History. Sie erscheinen auch in IDE-Einstellungen, CLI-Daten, lokalen Logs und temporären Debugging-Dateien.
Viele dieser Credentials erreichen Git nie. Das gilt besonders für die Laptops von sogenannten Citizen Coders, also Menschen, die ausschließlich auf localhost deployen.
KI-Coding-Agents können trotzdem auf sie stoßen. Agents können Dateien lesen, Befehle ausführen und Anwendungsausgaben inspizieren. Sie können zudem MCP-Server aufrufen, die Credentials als Teil einer Antwort zurückgeben.
Die Forschung von GitGuardian zeigt tatsächlich nur die Spitze dieses Eisbergs, da sie sich ausschließlich auf committeten Code bezieht: Öffentliche Commits mit Unterstützung von Claude Code wiesen eine Leckrate von 3,2 Prozent auf, verglichen mit einer Basisrate von 1,5 Prozent über alle öffentlichen GitHub-Commits. MCP kommt als weitere Quelle hinzu: In öffentlichen MCP-Konfigurationsdateien wurden 24.008 eindeutige Geheimnisse gefunden, darunter 2.117 gültige Credentials.
Öffentliche Repositories zeigen den sichtbaren Teil der Credential-Offenlegung. Der Entwickler-Endpunkt birgt einen deutlich größeren Pool potenzieller Geheimnisse. Lokale Konfigurationen, der Befehlsverlauf, Anwendungsdaten und KI-Tooling können allesamt Credentials enthalten, die nie in einem Repository erscheinen.
LLMs können Credentials daher von beiden Enden des Entwicklungszyklus aus begegnen. Öffentliche Daten können alte Offenlegungen in das Modelltraining einschleppen. KI-Agenten können frische Geheimnisse direkt aus den Umgebungen ziehen, in denen Entwickler arbeiten.
KI-Coding-Agents haben alle ein Modell im Kern, das Prompts und Daten als Tokens aufnimmt und generierte Antworten zurückliefert. Die Toolkette um dieses LLM herum bestimmt, wie Credentials ein Modell erreichen können.
Der Entwickler muss den API-Schlüssel niemals selbst in den Prompt kopieren. Das Credential kann in die Interaktion gelangen, während der Agent den Kontext sammelt, der zur Lösung des Problems nötig ist.
Ein Entwickler könnte einen Agenten bitten, eine API-Verbindung zu debuggen. Der Agent könnte eine.env-Datei lesen, eine Cloud-Konfiguration inspizieren oder Anwendungslogs durchsuchen. Er könnte auch einen Shell-Befehl ausführen oder einen MCP-Server aufrufen.
Traditionelle Ansätze des Secret Scannings, die auf Repository- und CI-Scans setzen, entdecken diese Offenlegung möglicherweise nie, weil es womöglich keinen Commit oder Pull Request gibt. Das Geheimnis kann direkt vom Entwickler-Endpunkt in einen KI-Workflow gelangen.
KI-Agenten betreten Umgebungen, in denen Credentials bereits über die Systeme der Entwickler verstreut sind. Mehr Autonomie gibt diesen Agenten mehr Gelegenheiten, auf sie zu treffen.
An dieser Stelle muss man klarstellen, dass Modellexposition und Modelltraining getrennte Themen sind. Ein Credential kann ein LLM erreichen, ohne zu Trainingsdaten zu werden. Enterprise-KI-Anbieter können einschränken, ob Prompts und Ausgaben für das Training verwendet werden.
Die Credential-Exposition passiert früher, nämlich wenn ein Agent ein Geheimnis aus der Entwicklungsumgebung hinausversendet. Ab diesem Zeitpunkt müssen Sicherheitsteams wissen, wohin das Credential gelangt ist, wie lange es dort gespeichert werden kann und ob es noch als vertrauenswürdig gelten darf.
Das Training ist nur eines von mehreren möglichen Zielen. Der Modellkontext ist das unmittelbare Problem. Was macht das Modell mit dem Geheimnis, das es dort findet?
Der stärkste Kontrollpunkt liegt vor der Übertragung. KI-Agenten können beim Lesen von Dateien, Ausführen von Befehlen oder Aufrufen von Tools auf Geheimnisse stoßen. Sicherheitskontrollen müssen diese Interaktionen inspizieren, bevor Credentials Teil des Modellkontexts werden.
Damit entsteht eine neue Credential-Grenze am Entwickler-Endpunkt und innerhalb des Agenten-Workflows.
Der beste Ort, um die Exposition von LLM-Credentials zu verhindern, ist bevor das Geheimnis das Modell erreicht. Am besten gelingt das mit deterministischen Werkzeugen rund um den Workflow des Agenten.
GitGuardian AI Hooks setzen Kontrollen direkt um die Aktionen von KI-Coding-Agents herum. Die GitGuardian CLI, ggshield, kann den Prompt eines Entwicklers vor dem Absenden scannen und Dateizugriffe, Shell-Befehle sowie MCP-Aufrufe vor deren Ausführung inspizieren. Wird ein Geheimnis erkannt, kann die Aktion blockiert werden, bevor das Credential das Modell erreicht. Die Untersuchung erfolgt auch bei jeder Tool-Ausgabe, sodass Antworten, die Geheimnisse enthalten, gar nicht erst an das Modell weitergegeben werden.
Alles, was man einen Agenten auffordert zu tun, ist nur ein Vorschlag; er befolgt es möglicherweise oder auch nicht, wie wir es aus unzähligen Geschichten über übergriffige Agenten kennen. Im Gegensatz zu Skills, Markdown oder Systemprompts greifen AI Hooks an vorhersehbaren Punkten im definierten Workflow des Agenten. Sie liegen außerhalb der Reichweite des Agenten und arbeiten auf Systemebene, an der Schnittstelle, an der der Agent mit der Umgebung interagiert. Ein deterministisches Werkzeug auf deterministische Weise aufzurufen ist der Weg vom bloßen Vorschlag, ein Geheimnis nicht zu verwenden, hin zum Anhalten einer Operation, die ein Geheimnis gegenüber dem LLM oder anderswo offengelegt hätte.
GitGuardian arbeitet daran, die gesamte Credential-Ebene abzusichern. Aus diesem Grund hat GitGuardian Developer Endpoint Protection eingeführt, um Entwicklergeräte nach Credentials zu durchsuchen, die in lokalen Dateien und lokalen Speichern liegen. Wir geben Sicherheitsteams Einblick darüber, welche Tools laufen und auf welche Ressourcen die Agenten zugreifen können, alles über eine einheitliche Oberfläche für Secrets-Sicherheit. Diese Funktionen lassen sich über verwaltete Gerätepools hinweg mit Jamf, Iru, Intune und anderen MDM-Lösungen bereitstellen, statt sich darauf zu verlassen, dass einzelne Entwickler ihre Schutzeinstellungen selbst vornehmen.
Das befähigt Sicherheitsteams, mit Entwicklern aus allen Abteilungen zusammenzuarbeiten, um die Anzahl gefährlicher Klartext-Credentials zu reduzieren, die ein Agent finden könnte.
Geheimnisse, die Anwendungen und Entwickler benötigen, gehören in verwaltete Vaults. Die Secrets-Manager-Integrationen von GitGuardian können erkennen, ob offengelegte Credentials bereits im Vault hinterlegt sind, Vorfälle mit Vault-Kontext verknüpfen und dabei helfen, nicht verwaltete Geheimnisse in sichere Speicher zu überführen. Dieser Kontext beschleunigt auch die Behebung, indem er Teams zeigt, wo das verwaltete Geheimnis liegt, welcher Kontext es umgibt und wer handeln muss.
Die Reduzierung der Credentials auf Entwickler-Endpunkten sollte ein erklärtes Ziel jedes Sicherheitsprogramms sein. Alle Geheimnisse, die weiterhin in den Händen der Entwickler verbleiben müssen, sollten ordnungsgemäß gepflegt und so eng wie möglich eingegrenzt werden, sodass sie nur den kleinstmöglichen Zugriff gewähren, den der Entwickler noch benötigt.
Teams muessen Kontrollen um KI-Agenten herum etablieren, bevor diese Anmeldedaten in ein anderes System tragen koennen.
GitGuardian kann diese Kontrollen bereits heute einrichten und organisationsweit skalieren. Jedes Geheimnis, das gestoppt wird, bevor es ein LLM erreicht, ist ein Zugangsdatum weniger, das ein KI-Agent preisgeben kann, ein Vorfall weniger, der behoben werden muss, und ein Geheimnis weniger, das in den nachgelagerten Datenlebenszyklus gelangen kann, der moeglicherweise irgendwann das Modelltraining einschliesst.
Die Black-box-LLM-Forschung zeigt, wie weit ein geleakter Berechtigungsnachweis reisen kann, bis hin zu den Trainingsdaten. Klartext-Geheimnisse bringen Gefahr mit sich, wo immer sie auftauchen, denn zu ihrer Nutzung ist kein weiterer Identitaetsnachweis noetig. Wer die Zeichenkette besitzt, kann versuchen, sich anzumelden.
Gleichzeitig sind die Handlungen eines KI-Agenten nicht deterministisch und damit unvorhersehbar. Zu versuchen, jedes moegliche Agentenverhalten zu kontrollieren, ist zum Scheitern verurteilt, denn dieses Regelwerk wuerde unendlich gross, selbst wenn KI beim Verfassen hilft.
Der praktischste Ansatz besteht darin, weniger Klartext-Geheimnisse in Reichweite zu halten, einzuschraenken, worauf Agenten zugreifen koennen, und Zugangsdaten zu stoppen, bevor sie sich weiter verbreiten.
GitGuardian hilft Entwicklern mit AI Hooks dabei, diese Kontrollen einzurichten. Einzelpersonen oder Open-Source-Projekte koennen diese Kontrolle ab heute kostenlos nutzen.
Fuer Organisationen, die denselben Schutz fuer eine ganze Flotte von Entwickler-Endgeraeten benoetigen, kann GitGuardian dabei helfen, diese Kontrollen grossflaechig auszurollen und zugleich das eigene Secrets-Sicherheitsprogramm weiterzuentwickeln.
Die Leckage von LLM-API-Schluesseln bezeichnet die Preisgabe von Zugangsdaten ueber grosse Sprachmodelle. Sie kann nachgelagert geschehen, wenn ein Schluessel aus oeffentlichem Code gelernt und spaeter in der Modellausgabe reproduziert wird, und sie kann unmittelbar geschehen, wenn ein KI-Agent waehrend der normalen Entwicklungsarbeit einen frischen Berechtigungsnachweis in den Modellkontext uebertraegt.
Was haben Forscher festgestellt, als sie LLMs auf geleakte API-Schluessel untersuchten?
Die Forscher hinter der Studie "Practical Secrets Extraction against Black-box LLMs" konnten aus allen drei getesteten Modellen echte Zugangsdaten-Zeichenketten wiederherstellen, wobei sie ausschliesslich Zugriff auf die API-Ausgabe hatten und weder Modellgewichte noch Token-Wahrscheinlichkeiten nutzen konnten. Qwen3-27B gab zwei DeepSeek-Schluessel und einen Google-Schluessel preis, GPT-Codex 5.3 einen DeepSeek-Schluessel und Claude Haiku 4.5 zwei DeepSeek-Schluessel. Jeder wiederhergestellte Schluessel hatte eine uebereinstimmende oeffentliche Vorkommensstelle auf GitHub.
Oeffentliche Repositories sind eine Quelle, da Code mit preisgegebenen Zugangsdaten Teil von Datensaetzen werden kann, die zum Trainieren oder Evaluieren von Modellen verwendet werden. GitGuardian erkannte 2025 28,65 Millionen neue hartcodierte Geheimnisse in oeffentlichen GitHub-Commits. KI-Agenten bringen eine unmittelbarere Quelle hinzu: den Entwickler-Laptop, auf dem.env-Dateien, Cloud-Konfigurationen, Shell-Historien und MCP-Einstellungen Zugangsdaten enthalten, die niemals Git erreichen.
Wie geben KI-Coding-Agenten Geheimnisse an LLMs preis?
Ein Agent, der eine API-Verbindung behebt, koennte eine.env-Datei lesen, eine Cloud-Konfiguration einsehen, Anwendungsprotokolle durchsuchen, einen Shell-Befehl ausfuehren oder einen MCP-Server aufrufen. Jede dieser Handlungen kann dazu fuehren, dass ein Berechtigungsnachweis in den Kontext gelangt, der an das Modell gesendet wird, und der Entwickler muss den Schluessel niemals in einen Prompt einfuegen.
Wird ein an ein LLM gesendetes Geheimnis zu Trainingsdaten?
Nicht automatisch. Die Exposition des Modells und das Modelltraining sind getrennt zu betrachten, und Enterprise-KI-Anbieter koennten einschraenken, ob Prompts und Ausgaben zum Training verwendet werden. Die Exposition geschieht dennoch frueher, naemlich wenn ein Agent ein Geheimnis aus der Entwicklungsumgebung hinaussendet, weshalb Teams wissen muessen, wohin der Berechtigungsnachweis gelangt ist und ob er weiterhin als vertrauenswuerdig gelten darf.
Wie kann ich verhindern, dass KI-Agenten Geheimnisse an ein LLM senden?
Nutzen Sie deterministische Kontrollen rund um den Arbeitsablauf des Agenten. GitGuardian AI Hooks verwenden ggshield, um Prompts vor dem Absenden zu scannen, Dateizugriffe, Shell-Befehle und MCP-Aufrufe vor der Ausfuehrung zu pruefen und nutzerausgaben mit Geheimnissen gegenueber dem Modell zurueckzuhalten. Developer Endpoint Protection verringert zudem, wie viele Klartext-Zugangsdaten ein Agent finden kann, und laesst sich ueber MDM-Loesungen wie Jamf, Iru und Intune verwaltet in gesamten Flotten ausrollen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 21 • Originally published at blog.gitguardian.com
More and more teams are adopting AI agents, allowing them to create new tools, apps, and software at unprecedented speed. At the core of every connection these apps require is a credential, often in the form of an API key.
Those keys get leaked every time they are touched by the AI, and in ways that might not be obvious at first glance.
A coding agent can read a local configuration file, run a command, or call a Model Context Protocol (MCP) server. Any of those actions can place a credential into the context sent to a large language model (LLM).
Recent research shows that exposed credentials can also survive much farther downstream. Researchers behind " Practical Secrets Extraction against Black-box LLMs " recovered strings matching real API keys from Qwen3-27B, GPT-Codex 5.3, and Claude Haiku 4.5 using output-only access.
Very importantly, they had no access to model weights or token probabilities. This was done completely through "API output-only access."
LLM API key leakage now reaches across the credential lifecycle. Existing credentials are now part of training data and can and do appear in model output. AI agents can also move fresh credentials into model context during normal development work.
The researchers recovered real credential strings from three black-box LLMs. All three exposed a secret.
Qwen3-27B returned two DeepSeek keys and one Google key. GPT-Codex 5.3 returned a DeepSeek key. Claude Haiku 4.5 returned two DeepSeek keys.
They then searched GitHub for each complete credential and found a public match every time. That supports the conclusion that the models reproduced real leaked secrets rather than generating strings that only looked valid.
The researchers stopped there. They masked the credentials and did not test whether the keys still worked.
An attacker or rogue agent would have no reason to stop. A recovered key could be tested, used to access downstream systems, or abused until it is revoked, as we have seen across many attacks.
What caught our attention about this paper is that black-box, read only access alone can be enough to recover memorized credentials from model output. The next obvious question is, how did those keys get there?
LLMs can find API keys in public training data, and we know there are a lot there, but AI agents create a more immediate source: the developer laptop.
Public repositories can become part of datasets used to train or evaluate models. Once a credential appears in public code, it can also spread through forks, copied examples, logs, and other development artifacts. This happens a lot.
GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025. Credentials tied to AI services reached 1,275,105, an 81% increase year over year.
The black-box LLM research shows the downstream result. Researchers recovered credential strings from deployed models and found matching public occurrences on GitHub for every recovered key.
Developer laptops have quietly become credential stores. Secrets live in.env files, cloud configuration files, and shell history. They also appear in IDE settings, CLI data, local logs, and temporary debugging files.
Many of those credentials never reach Git. This is especially true on 'citizen coders' laptops where people are only ever deploying to localhost.
AI coding agents can still encounter them. Agents can read files, run commands, and inspect application output. They can also call MCP servers that return credentials as part of a response.
GitGuardian's research really reveals just the tip of this iceberg, looking just at committed code: Claude Code-assisted public commits had a 3.2% secret leak rate, compared with a 1.5% baseline across public GitHub commits. MCP adds another source: 24,008 unique secrets were found in public MCP configuration files, including 2,117 valid credentials.
Public repositories show the part of credential exposure that becomes visible. The developer endpoint holds a much larger pool of potential secrets. Local configurations, command history, application data, and AI tooling can all contain credentials that never appear in a repository.
LLMs can therefore encounter credentials from both ends of the development lifecycle. Public data can carry old exposures into model training. AI agents can pull fresh secrets directly from the environments where developers work.
AI coding agents all have a model at their core, taking prompts and data in as tokens and returning generated replies. The tool chain around this LLM defines how credentials can reach a model.
The developer never needs to copy the API key into the prompt. The credential can enter the interaction as the agent gathers context needed to solve the problem.
A developer might ask an agent to troubleshoot an API connection. The agent could read an.env file, inspect a cloud configuration, or search application logs. It could also run a shell command or call an MCP server.
Traditional approaches to secret scanning focused on repository and CI scanning may never see this exposure because there may be no commit or pull request. The secret can move directly from the developer endpoint into an AI workflow.
AI agents are entering environments where credentials are already scattered across developer systems. More autonomy gives those agents more opportunities to encounter them.
We do need to acknowledge here that model exposure and model training are separate concerns. A credential can reach an LLM without becoming training data. Enterprise AI providers may limit whether prompts and outputs are used for training.
Credential exposure happens earlier, when an agent sends a secret outside the developer environment. Once that happens, security teams need to know where the credential went, how long it may be retained, and whether it should still be trusted.
Training is one possible destination. Model context is the immediate concern. What will it do with that secret it finds?
The strongest control point sits before transmission. AI agents can encounter secrets while reading files, running commands, or calling tools. Security controls need to inspect those interactions before credentials become part of model context.
That creates a new credential boundary at the developer endpoint and inside the agent workflow.
The best place to stop LLM credential exposure is before the secret reaches the model. The best way to do that is with deterministic tools around the agent's workflow.
GitGuardian AI Hooks put controls directly around the actions AI coding agents take. The GitGuardian CLI, ggshield, can scan a developer's prompt before submission and inspect file reads, shell commands, and MCP calls before execution. When a secret is detected, the action can be blocked before the credential reaches the model. Scanning also happens at any tool output, withholding secret-bearing responses from being passed to the model entirely.
Anything you ask an agent to do is a suggestion; it might or might not follow it, as we have seen in countless rogue agent stories. Unlike skills, Markdown, or system prompts, AI hooks fire at predictable points along the agent's defined workflow. They are outside the reach of the agent, working at the system level where the agent interacts with the environment. Calling a deterministic tool in a deterministic way is how you go from suggesting the agent not use a secret to halting an operation that would have exposed a secret to the LLM or elsewhere.
GitGuardian is working to secure the entire credential layer. That is why GitGuardian introduced Developer Endpoint Protection to scan developer machines for credentials sitting in local files and local storage. We are giving security teams visibility into which tools are running and what resources the agents can reach, all from one unified secrets security interface. These capabilities can be deployed across managed fleets through Jamf, Iru, Intune, and other MDM solutions, rather than relying on individual developers to configure protections themselves.
This empowers security teams to work with developers, no matter what department they work in, to reduce how many dangerous plaintext credentials are available for an agent to find.
Secrets needed by applications and developers belong in managed vaults. GitGuardian's secrets manager integrations can identify whether exposed credentials are already vaulted, connect incidents with vault context, and help move unvaulted secrets into secure storage. That context also makes remediation faster by showing teams where the managed secret lives, the full context around it, and who needs to act.
Reducing the credentials sitting on developer endpoints should be a stated goal of a security program. Any secrets that do need to remain in the hands of the developer should be properly maintained and scoped as tightly as possible to only the smallest needed access the developer can still use.
Teams need to work to place controls around AI agents before they can carry credentials into another system.
GitGuardian can put those controls in place today and scale them across the organization. Every secret stopped before it reaches an LLM is one less credential an AI agent can expose, one less incident to remediate, and one less secret that can enter the downstream data lifecycle that may eventually include model training.
The black-box LLM research shows how far a leaked credential can travel, all the way into training data. Plaintext secrets bring danger wherever they appear because they require no additional proof of identity to use. If you have the string, you can try to log in.
At the same time, the actions an AI agent takes are non-deterministic and therefore unpredictable. Trying to control every possible agent behavior is a non-starter because that rule set becomes infinitely large, even if AI helps write it.
The most practical approach is to keep fewer plaintext secrets within reach, limit what agents can access, and stop credentials before they travel any farther.
GitGuardian is here to help developers put those controls in place with AI Hooks. You can start using this control today for free as an individual or open-source project.
For organizations that need the same protection across an entire fleet of developer endpoints, GitGuardian can help roll those controls out at scale while helping you evolve your secrets security program.
LLM API key leakage is the exposure of credentials through large language models. It can happen downstream, when a key from public code is memorized and later reproduced in model output, and it can happen immediately, when an AI agent moves a fresh credential into model context while doing normal development work.
What did researchers find when they tested LLMs for leaked API keys?
The researchers behind "Practical Secrets Extraction against Black-box LLMs" recovered real credential strings from all three models they tested, using only API output access and no model weights or token probabilities. Qwen3-27B returned two DeepSeek keys and one Google key, GPT-Codex 5.3 returned a DeepSeek key, and Claude Haiku 4.5 returned two DeepSeek keys. Every recovered key had a matching public occurrence on GitHub.
Public repositories are one source, since code with exposed credentials can become part of datasets used to train or evaluate models. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025. AI agents add a more immediate source, the developer laptop, where.env files, cloud configurations, shell history, and MCP settings hold credentials that never reach Git.
How do AI coding agents expose secrets to LLMs?
An agent troubleshooting an API connection might read an.env file, inspect a cloud configuration, search application logs, run a shell command, or call an MCP server. Any of those actions can put a credential into the context sent to the model, and the developer never has to paste the key into a prompt.
Does a secret sent to an LLM become training data?
Not automatically. Model exposure and model training are separate concerns, and enterprise AI providers may limit whether prompts and outputs are used for training. The exposure still happens earlier, when an agent sends a secret outside the developer environment, so teams need to know where the credential went and whether it should still be trusted.
How can I stop AI agents from sending secrets to an LLM?
Use deterministic controls around the agent's workflow. GitGuardian AI Hooks use ggshield to scan prompts before submission, inspect file reads, shell commands, and MCP calls before execution, and withhold secret-bearing tool output from the model. Developer Endpoint Protection then reduces how many plaintext credentials are available for an agent to find, and can be deployed across managed fleets through MDM solutions like Jamf, Iru, and Intune.