Secrets und API-Keys bei KI-Agenten schützen: .env, Vault und Berechtigungen richtig einsetzen

KI-Agenten bekommen immer mehr Fähigkeiten. Sie lesen Dateien, führen Shell-Befehle aus, greifen auf Git-Repositories zu, kommunizieren mit Datenbanken, bedienen APIs oder verwenden über MCP angebundene Werkzeuge.

Genau darin liegt jedoch ein erhebliches Sicherheitsrisiko.

Ein klassisches Programm bekommt vielleicht einen API-Key und verwendet ihn für einen genau definierten Zweck. Ein autonom arbeitender KI-Agent besitzt dagegen möglicherweise gleichzeitig Zugriff auf das Dateisystem, die Shell, Netzwerkdienste und weitere Tools.

Liegt dann irgendwo eine Datei wie diese herum:

OPENAI_API_KEY=sk-xxxxxxxx
GITHUB_TOKEN=github_pat_xxxxxxxx
DATABASE_PASSWORD=SuperGeheim123
AWS_SECRET_ACCESS_KEY=xxxxxxxx

kann aus einem eigentlich kleinen Konfigurationsfehler plötzlich ein ernstes Sicherheitsproblem werden.

Die wichtigste Regel lautet deshalb:

Ein KI-Agent sollte niemals mehr Secrets sehen oder verwenden können, als er für seine aktuelle Aufgabe tatsächlich benötigt.

Das betrifft sowohl ChatGPT- oder Claude-basierte Agenten als auch Coding-Agenten, selbst entwickelte Agentensysteme, MCP-Server, CI/CD-Agenten und lokale KI-Tools.

OWASP empfiehlt für Secrets unter anderem zentrale Verwaltung, Least Privilege, automatisierte Rotation, kurze Lebensdauer und die Vermeidung unnötiger menschlicher Zugriffe auf die eigentlichen Zugangsdaten.

Warum Secrets bei KI-Agenten besonders kritisch sind

API-Keys sind grundsätzlich nichts Neues. Doch KI-Agenten verändern das Bedrohungsmodell.

Ein Agent kann möglicherweise:

• Dateien durchsuchen
• Konfigurationsdateien öffnen
• Terminalbefehle ausführen
• Logs analysieren
• Git-Historien durchsuchen
• HTTP-Anfragen senden
• Datenbanken abfragen
• MCP-Tools starten
• Cloud-Ressourcen verändern

Damit besitzt ein Agent unter Umständen genau die Funktionen, die ein Angreifer benötigt, um ein gefundenes Secret auch unmittelbar zu verwenden.

Hinzu kommt der Kontext eines KI-Systems. Wird ein Secret beispielsweise versehentlich Bestandteil eines Prompts, eines Tool-Ergebnisses oder eines Debug-Logs, besteht das Risiko, dass es weiterverarbeitet oder gespeichert wird.

OWASP führt „Token Mismanagement and Secret Exposure" deshalb inzwischen ausdrücklich als Risiko für MCP-basierte Systeme auf. Dabei wird unter anderem davor gewarnt, Tokens in Konfigurationsdateien, Prompt-Templates oder dauerhaftem Modellkontext abzulegen. Empfohlen werden kurzlebige, eingeschränkte Tokens sowie eine Trennung von Kontext und Berechtigungen.

Besonders kritisch wird es, wenn KI-Tools ganz ohne offizielle Freigabe im Unternehmen zum Einsatz kommen. Fehlt dafür eine zentrale Übersicht und Richtlinie, landen Zugangsdaten schnell in nicht genehmigten Tools und Umgebungen, in denen niemand ihre Sicherheit kontrolliert – mehr dazu in Shadow AI verhindern: Technische und organisatorische Maßnahmen (Zum Artikel).

Die drei Ebenen sicherer Secret-Verwaltung

Für KI-Agenten sollte man Secrets auf drei Ebenen betrachten:

1. Speicherung: Wo befindet sich das Secret?
2. Bereitstellung: Wie bekommt der Agent das Secret?
3. Berechtigung: Was darf er damit tun?

Viele Installationen kümmern sich lediglich um Punkt eins.

Das reicht nicht.

Ein perfekt verschlüsselter API-Key hilft wenig, wenn der daraus erzeugte Token anschließend Administratorrechte auf die komplette Infrastruktur besitzt.

Variante 1: .env – praktisch, aber kein Secret Vault

Eine der verbreitetsten Varianten in Entwicklungsprojekten ist eine .env-Datei.

Beispiel:

OPENAI_API_KEY=your-api-key
DATABASE_HOST=db01.internal
DATABASE_USER=agent
DATABASE_PASSWORD=your-password

Die Anwendung liest diese Werte beim Start ein.

Für lokale Entwicklungsumgebungen ist dieses Verfahren einfach und bequem.

Es hat jedoch Grenzen.

.env unbedingt aus Git ausschließen

Eine .env-Datei mit echten Zugangsdaten gehört niemals in ein Git-Repository.

Eine passende .gitignore könnte beispielsweise so aussehen:

.env
.env.*
!.env.example

Eine .env.example enthält dagegen ausschließlich die benötigten Variablennamen:

OPENAI_API_KEY=
DATABASE_HOST=
DATABASE_USER=
DATABASE_PASSWORD=

Damit weiß ein Entwickler, welche Einstellungen benötigt werden, ohne dass echte Credentials veröffentlicht werden.

GitHub bietet zusätzlich Secret Scanning und Push Protection an. Push Protection kann erkannte API-Keys und andere Zugangsdaten bereits beim Push blockieren, bevor sie überhaupt im Repository landen. GitHub scannt außerdem die Git-Historie nach bekannten Secret-Mustern.

Das ist insbesondere bei Projekten mit Coding-Agenten sinnvoll. Denn ein Agent kann genauso versehentlich eine Konfigurationsdatei committen wie ein Mensch.

Dateirechte nicht vergessen

Auf Linux-Systemen sollte eine lokale Secret-Datei nur für den Benutzer lesbar sein, der sie wirklich benötigt.

Beispiel:

chmod 600 .env

Anschließend:

ls -l .env

Erwartetes Ergebnis:

-rw------- 1 agent agent 512 Aug 31 10:00 .env

Noch besser ist es, den eigentlichen Agent-Prozess unter einem eigenen Servicekonto laufen zu lassen.

Also beispielsweise:

agent-research
agent-github
agent-monitoring
agent-deployment

statt:

root

oder eines gemeinsamen Administratorkontos.

Warum .env für Produktion häufig nicht reicht

Eine .env-Datei löst vor allem ein organisatorisches Problem: Secrets müssen nicht mehr direkt im Quellcode stehen.

Sie wird dadurch jedoch nicht automatisch zu einem sicheren Secrets-Management-System.

Umgebungsvariablen können beispielsweise durch Debug-Ausgaben, Diagnosedaten, Dumps oder falsch konfigurierte Logs offengelegt werden. OWASP empfiehlt deshalb, Environment Variables für Secrets nur dann zu verwenden, wenn geeignetere Mechanismen nicht zur Verfügung stehen.

Eine gute Faustregel lautet daher:

Umgebung	Empfehlung
Lokale Entwicklung	.env akzeptabel
Testsystem	Secret Store bevorzugen
CI/CD	CI Secret Store
Docker Produktion	Docker Secrets / Secret Store
Kubernetes	Secret Manager / externe Secret-Lösung
Kritische Produktion	Vault oder vergleichbare Lösung
KI-Agent mit Infrastrukturzugriff	Vault + Least Privilege

.env ist also nicht grundsätzlich schlecht. Sie sollte lediglich nicht mit einem echten Vault verwechselt werden.

Variante 2: HashiCorp Vault und zentrale Secret Stores

Sobald mehrere Server, Dienste oder Agenten beteiligt sind, wird ein zentraler Secret Store interessant.

Ein bekanntes Beispiel ist HashiCorp Vault.

Statt einen Datenbank-Key dauerhaft im Projekt abzulegen, authentifiziert sich die Anwendung gegenüber Vault und bekommt nur das Secret, das sie benötigt.

Das grundlegende Prinzip sieht dann so aus:

KI-Agent
   │
   │ authentifiziert sich
   ▼
Vault
   │
   │ prüft Policy
   ▼
freigegebenes Secret
   │
   ▼
API / Datenbank / Dienst

Vault verwendet Policies, um festzulegen, welche Pfade eine Anwendung lesen oder verändern darf. Nicht ausdrücklich erlaubte Zugriffe werden standardmäßig verweigert. HashiCorp empfiehlt dabei ausdrücklich einfache und möglichst eingeschränkte Policies nach dem Least-Privilege-Prinzip.

Beispiel: Ein Agent darf genau ein Secret lesen

Angenommen, ein Monitoring-Agent benötigt lediglich Zugriff auf:

secret/data/agents/monitoring

Dann sollte seine Vault-Policy nicht so aussehen:

path "secret/*" {
  capabilities = ["read"]
}

Damit könnte der Agent sämtliche dort abgelegten Secrets lesen.

Deutlich besser wäre:

path "secret/data/agents/monitoring" {
  capabilities = ["read"]
}

Der Agent kann jetzt genau den Pfad lesen, den er benötigt. Nicht mehr.

Dieses Prinzip sollte sich durch die komplette Agentenarchitektur ziehen.

Noch besser: dynamische Secrets

Ein besonders interessantes Konzept von Vault sind Dynamic Secrets.

Anstatt beispielsweise für eine Datenbank dauerhaft Folgendes zu speichern:

username=agent
password=EinPasswortDasJahrelangGleichBleibt

kann Vault bei Bedarf temporäre Zugangsdaten erzeugen. Zum Beispiel:

username=v-agent-f8a731
password=RandomGeneratedPassword
gültig=60 Minuten

Nach Ablauf der vorgesehenen Zeit verlieren diese Zugangsdaten ihre Gültigkeit.

Vault verwendet dafür Leases und Time-to-Live-Werte. Dynamisch erzeugte Credentials können nach Ablauf automatisch widerrufen werden. Für Datenbanken kann Vault sogar jeweils eigene Benutzer für einzelne Dienste oder Instanzen erzeugen, wodurch sich Zugriffe besser zuordnen lassen.

Das ist für KI-Agenten äußerst interessant. Ein Agent benötigt dann keinen Datenbankzugang, der fünf Jahre gültig ist.

Er benötigt möglicherweise nur:

DB-Account
Gültigkeit: 30 Minuten
Rechte: SELECT
Datenbank: reporting

und genau das bekommt er.

Das wichtigste Sicherheitsprinzip: Least Privilege

Der sichere Speicherort eines API-Keys ist nur die halbe Lösung.

Mindestens genauso wichtig sind die Rechte dieses Keys. Wie du solche Rechte für KI-Agenten grundsätzlich zuschneidest, erklärt Welche Rechte darf ein KI-Agent bekommen? Sicherheitsregeln für Agenten (Zum Artikel).

Ein KI-Agent, der GitHub-Issues analysieren soll, benötigt beispielsweise nicht automatisch:

Repository löschen
Branches löschen
Secrets verändern
Actions konfigurieren
Benutzer verwalten

Vielleicht benötigt er lediglich:

Issues: Read
Repository Content: Read
Metadata: Read

Das Gleiche gilt für Datenbanken.

Ein Reporting-Agent braucht häufig:

SELECT

aber nicht:

DROP
ALTER
DELETE
CREATE USER
GRANT

Und ein Monitoring-Agent benötigt unter Umständen Zugriff auf:

GET /api/status
GET /api/metrics

aber nicht:

POST /api/shutdown
DELETE /api/server

OWASP empfiehlt bei Secrets explizit fein abgestufte Zugriffskontrollen und Least Privilege. Personen oder Anwendungen sollten nicht pauschal Zugriff auf alle Secrets eines zentralen Secret Stores erhalten.

Ein Agent – eine Identität

Eine gefährliche Konfiguration sieht folgendermaßen aus:

MASTER_API_TOKEN=xxxxxxxx

und anschließend verwenden zehn verschiedene Agenten denselben Token.

Das ist bequem. Aber sicherheitstechnisch problematisch.

Besser:

agent-readonly-github
agent-monitoring
agent-backup-check
agent-deployment
agent-ticket-system

Jeder Agent bekommt:

• eine eigene Identität,
• eigene Credentials,
• eigene Berechtigungen,
• eigene Logs,
• eine eigene Lebensdauer der Tokens.

Wird dann agent-monitoring kompromittiert, muss nicht gleichzeitig der Deployment-Agent betroffen sein.

Außerdem lässt sich wesentlich einfacher nachvollziehen, welcher Agent eine bestimmte Aktion durchgeführt hat.

Besonders gefährlich: Agenten mit Root- oder Administratorrechten

Ein häufiger Fehler bei Coding-Agenten besteht darin, den Agenten einfach mit den Rechten des angemeldeten Administrators zu starten.

Beispielsweise:

sudo agent

und danach darf der Agent:

/etc lesen
Dienste stoppen
Pakete installieren
SSH-Schlüssel lesen
Netzwerkkonfiguration verändern
Docker administrieren
Dateien löschen

Das ist komfortabel. Es widerspricht aber dem Least-Privilege-Prinzip.

Ein Agent sollte nur die Werkzeuge und Betriebssystemrechte bekommen, die für seine konkrete Aufgabe notwendig sind.

Das kann beispielsweise bedeuten:

Agent
 ├── Projektverzeichnis: Read/Write
 ├── /etc/nginx/: Read
 ├── systemctl status nginx: erlaubt
 ├── journalctl nginx: erlaubt
 ├── systemctl restart nginx: nur nach Freigabe
 └── /root: kein Zugriff

Gerade bei produktiven Systemen ist diese Trennung entscheidend.

Secrets bei MCP-Servern besonders sorgfältig behandeln

MCP – das Model Context Protocol – ermöglicht es KI-Systemen, externe Werkzeuge und Datenquellen zu verwenden.

Ein MCP-Server könnte beispielsweise Zugriff besitzen auf:

GitHub
PostgreSQL
MySQL
Jira
Slack
Dateisysteme
Kubernetes
Monitoring
interne REST-APIs

Dadurch wird der MCP-Server zu einer besonders kritischen Sicherheitskomponente. Wie du einen MCP Server insgesamt sicher betreibst, zeigt MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel).

API-Keys sollten deshalb nicht einfach direkt in eine gemeinsam genutzte Agenten- oder MCP-Konfiguration geschrieben werden.

OWASP empfiehlt im Zusammenhang mit MCP unter anderem:

• Secrets in Vault-Systemen speichern,
• Tokens nur zur Laufzeit bereitstellen,
• kurzlebige Tokens verwenden,
• Tokens an konkrete Agenten, Tools oder Sessions binden,
• Secrets aus Logs entfernen,
• Credentials bei einem Verdacht sofort rotieren beziehungsweise ungültig machen.

Ein MCP-Agent für GitHub sollte beispielsweise keinen AWS-Key kennen. Und ein Datenbank-Agent muss keinen Zugriff auf den Deployment-Token besitzen.

Agenten vom Secret selbst fernhalten

Eine interessante Architektur besteht darin, dem Sprachmodell das eigentliche Secret überhaupt nicht zu zeigen.

Statt:

Agent bekommt API-Key
      ↓
Agent erstellt HTTP Request

besser:

Agent
  ↓
freigegebenes Tool
  ↓
Credential Proxy / MCP Server
  ↓
Secret Store
  ↓
API

Der Agent sagt beispielsweise lediglich:

create_github_issue(
    repository="firma/projekt",
    title="Fehler in Version 2.1"
)

Das Tool selbst authentifiziert sich gegenüber GitHub. Das Sprachmodell muss den GitHub-Token niemals kennen.

Dieses Muster reduziert die Anzahl der Komponenten, in denen das Secret überhaupt auftaucht. Wie du einen eigenen MCP Server als genau eine solche kontrollierte Zwischenschicht baust, zeigt Eigenen MCP Server erstellen: Architektur und Praxisbeispiel (Zum Artikel).

Docker: Secrets nicht in Dockerfiles einbauen

Ein besonders problematisches Beispiel wäre:

ENV OPENAI_API_KEY=sk-xxxxxxxx

oder:

ARG API_KEY=xxxxxxxx

Docker warnt ausdrücklich davor, sensible Daten über ARG oder ENV in Images einzubauen, da diese Informationen im resultierenden Image beziehungsweise dessen Metadaten verbleiben können. Für Builds empfiehlt Docker Secret Mounts.

Für Docker Compose stehen ebenfalls Secrets zur Verfügung.

Ein Dienst bekommt dann ausschließlich die für ihn ausdrücklich freigegebenen Secrets. Docker empfiehlt diese Variante gegenüber der Übergabe sensibler Daten als normale Umgebungsvariablen.

Das Prinzip ist wiederum dasselbe: Das Secret nur dort sichtbar machen, wo es tatsächlich gebraucht wird.

Auch .agentsignore ist keine echte Sicherheitsgrenze

Ein weiterer wichtiger Punkt für Coding-Agenten: Dateien wie .env können teilweise über Ignore-Dateien aus dem normalen Agentenkontext ausgeschlossen werden.

Das ist sinnvoll. Es ersetzt aber keine Betriebssystemberechtigungen oder Sandbox.

Docker weist beispielsweise für seine Agenten darauf hin, dass eine Ignore-Regel verhindern kann, dass eine Secret-Datei über bestimmte Filesystem-Tools gelesen wird. Hat der Agent jedoch gleichzeitig Shell-Zugriff, könnte er theoretisch weiterhin beispielsweise Folgendes ausführen:

cat .env

Eine Ignore-Datei ist deshalb ein Schutzmechanismus gegen unbeabsichtigten Zugriff – keine harte Sicherheitsgrenze. Für kritische Secrets benötigt man echte Berechtigungsgrenzen wie Sandboxing, Freigaben und ein durchdachtes Backup-Konzept, etwa so, wie es sich bei Coding-Agenten wie Codex bewährt hat – siehe Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel).

Secrets gehören niemals in Prompts

Ebenfalls vermeiden sollte man Prompts wie:

Verbinde dich mit der API.

API-Key:
sk-xxxxxxxxxxxxxxxx

Analysiere anschließend ...

Besser ist:

Verwende das freigegebene monitoring_api Tool und analysiere
die aktuellen Systemmeldungen.

Die Authentifizierung erfolgt innerhalb des Tools. Der Agent benötigt weder den API-Key noch dessen Wert.

Das gilt genauso für:

• System-Prompts
• AGENTS.md
• CLAUDE.md
• README-Dateien
• MCP-Konfigurationen
• Knowledge Bases
• Agent Memory
• Tickets
• Chatverläufe

Gerade weil AGENTS.md und CLAUDE.md heute in sehr vielen Projekten die zentrale Arbeitsanweisung für Coding-Agenten sind, lohnt sich ein bewusster Blick darauf, was dort hineingehört und was nicht – siehe AGENTS.md vs. CLAUDE.md: Welche Datei braucht dein Projekt? (Zum Artikel).

Ein Secret sollte niemals Bestandteil des normalen Wissenskontextes eines KI-Agenten werden.

Logs sind ein unterschätztes Risiko

Folgender Debug-Code kann fatale Folgen haben:

print(os.environ)

oder:

DEBUG configuration:
OPENAI_API_KEY=sk-xxxxxxxx
DATABASE_PASSWORD=xxxxxxxx

Damit liegt das Secret plötzlich möglicherweise in:

• journalctl
• Docker Logs
• Kubernetes Logs
• Elasticsearch
• Loki
• Splunk
• SIEM-Systemen
• CI/CD-Logs
• Debug-Reports

OWASP empfiehlt deshalb ausdrücklich, Secrets niemals im Klartext zu protokollieren und stattdessen Maskierung beziehungsweise Redaction einzusetzen.

Statt:

API_KEY=sk-proj-abc123xyz456

sollte beispielsweise nur erscheinen:

API_KEY=sk-proj-************

oder besser:

API credentials loaded successfully.

Was tun, wenn ein API-Key doch in Git landet?

Dann gilt: Nicht einfach nur die Datei löschen.

Der Key kann weiterhin in der Git-Historie vorhanden sein.

Die wichtigste Maßnahme ist zunächst: Secret widerrufen oder rotieren.

Anschließend sollte geprüft werden:

• Wo wurde der Key veröffentlicht?
• Seit wann war er dort vorhanden?
• Welche Rechte besitzt der Key?
• Wurde er bereits verwendet?
• Gibt es verdächtige API-Zugriffe?
• Befindet er sich zusätzlich in Logs?
• Befindet er sich in Forks oder Backups?
• Ist er Bestandteil eines Agenten-Kontextes geworden?

GitHub empfiehlt bei tatsächlich offengelegten Secrets ebenfalls, diese zu widerrufen und gegebenenfalls zunächst zu rotieren.

Erst danach sollte man sich um die Bereinigung der Repository-Historie kümmern.

API-Key-Rotation einplanen

Ein Secret sollte nicht erst dann ausgetauscht werden können, wenn ein Sicherheitsvorfall passiert.

Rotation gehört zur Architektur.

Ein guter Prozess ermöglicht:

alten Key aktiv
        ↓
neuen Key erzeugen
        ↓
Anwendungen umstellen
        ↓
Funktion prüfen
        ↓
alten Key deaktivieren

Bei dynamischen Secrets kann dieser Prozess weitgehend automatisiert werden.

OWASP empfiehlt automatische Rotation, wo immer dies sinnvoll möglich ist. HashiCorp Vault kann dynamische Zugangsdaten zudem mit einer definierten TTL versehen und nach Ablauf widerrufen.

Ein sinnvolles Berechtigungsmodell für KI-Agenten

Für produktive Agenten kann man beispielsweise folgende Klassifizierung verwenden:

Agentenklasse	Typische Rechte
Analyse-Agent	ausschließlich Lesen
Monitoring-Agent	Metrics und Logs lesen
Support-Agent	Tickets lesen und schreiben
Coding-Agent	Projektverzeichnis bearbeiten
Deployment-Agent	definierte Deployments starten
Admin-Agent	besonders eingeschränkte Sonderrolle

Interessant ist dabei: Der Admin-Agent sollte nicht automatisch der Standard sein.

Im Gegenteil. Je mächtiger der Agent, desto stärker sollten zusätzliche Kontrollen werden. Dazu gehören beispielsweise:

• Human Approval
• eingeschränkte Tool-Auswahl
• Command Allowlisting
• Netzwerkbegrenzung
• kurzlebige Credentials
• Session-Isolation
• Audit Logging
• Sandbox
• getrennte Service Accounts

Ein solches Berechtigungsmodell funktioniert in der Praxis nur, wenn es auch verbindlich dokumentiert ist. Genau dafür eignet sich eine unternehmensweite KI-Richtlinie – siehe KI-Richtlinie fürs Unternehmen: Was Mitarbeiter dürfen – und was nicht (Zum Artikel).

Drei Sicherheitsstufen für die Praxis

Stufe 1: Kleine lokale Entwicklungsumgebung

Geeignet für persönliche Entwicklungsprojekte.

• .env
• .gitignore
• chmod 600
• separater Entwicklungs-Key
• eingeschränkte API-Rechte
• Secret Scanning

Wichtig: Keine Produktions-Credentials verwenden.

Stufe 2: Server und Unternehmensanwendungen

Geeignet für produktive Dienste und interne Agenten.

• zentraler Secret Store
• separate Service Accounts
• Least Privilege
• CI/CD Secret Store
• Rotation
• Audit Logs
• getrennte Test-/Prod-Credentials

.env sollte hier nicht mehr die zentrale Secret-Datenbank darstellen.

Stufe 3: Kritische KI-Agenten

Geeignet für Agenten mit Zugriff auf Infrastruktur, Datenbanken, Git, Cloud oder Produktionssysteme.

• Vault / Secret Manager
• kurzlebige Credentials
• eigene Identität pro Agent
• Policy pro Tool
• keine Secrets im Modellkontext
• Human Approval für kritische Aktionen
• Sandbox
• zentrale Audit Logs
• automatische Rotation

Das ist deutlich aufwendiger. Aber genau diese Systeme besitzen auch das größte Schadenspotenzial.

Beispiel für eine sichere Agentenarchitektur

Eine robuste Architektur könnte beispielsweise so aussehen:

                    ┌─────────────────┐
                    │   KI-Modell     │
                    └────────┬────────┘
                             │
                    keine Credentials
                             │
                    ┌────────▼────────┐
                    │ Agent Runtime   │
                    └────────┬────────┘
                             │
                   definierte Tools
                             │
             ┌───────────────┴───────────────┐
             │                               │
      ┌──────▼──────┐                 ┌──────▼──────┐
      │ GitHub Tool │                 │ DB Tool     │
      └──────┬──────┘                 └──────┬──────┘
             │                               │
      eigener Token                   eigener Account
             │                               │
             └──────────────┬────────────────┘
                            │
                     ┌──────▼──────┐
                     │ Vault / IAM │
                     └─────────────┘

Der entscheidende Unterschied zu einer unsicheren Lösung: Das Modell bekommt keinen großen Satz an API-Keys übergeben.

Stattdessen besitzen einzelne Werkzeuge exakt definierte Identitäten und Berechtigungen.

Praktische Sicherheits-Checkliste

Vor dem produktiven Einsatz eines KI-Agenten sollten mindestens folgende Fragen beantwortet sein:

• Liegen API-Keys im Quellcode?
• Befinden sich Secrets in .env-Dateien innerhalb des Repositories?
• Ist .env in .gitignore eingetragen?
• Gibt es eine .env.example ohne Credentials?
• Werden Produktions-Secrets zentral gespeichert?
• Besitzt jeder Agent eine eigene Identität?
• Sind Test- und Produktions-Credentials getrennt?
• Sind die Rechte nach Least Privilege vergeben?
• Können Tokens zeitlich begrenzt werden?
• Gibt es einen dokumentierten Rotationsprozess?
• Werden Secrets aus Logs entfernt?
• Hat der Agent Zugriff auf Dateien, die er überhaupt nicht benötigt?
• Kann der Agent Shell-Befehle uneingeschränkt ausführen?
• Benötigt er wirklich Schreibrechte?
• Werden gefährliche Aktionen durch Human Approval geschützt?
• Werden Secrets im Agenten-Kontext oder Memory gespeichert?
• Können einzelne Tokens sofort widerrufen werden?
• Existiert Audit Logging?
• Werden Repositories automatisch auf Secrets geprüft?

Wenn mehrere dieser Fragen mit „Nein" beantwortet werden, sollte die Agentenarchitektur vor einem produktiven Einsatz noch einmal überprüft werden.

Fazit: Der beste API-Key ist der, den der Agent gar nicht kennt

KI-Agenten benötigen Zugriff auf Werkzeuge und Systeme.

Das bedeutet aber nicht automatisch, dass das Sprachmodell selbst sämtliche Zugangsdaten kennen muss.

Für lokale Entwicklung kann eine sauber geschützte .env-Datei vollkommen ausreichend sein.

Sobald jedoch produktive Systeme, mehrere Agenten oder kritische Berechtigungen ins Spiel kommen, sollte man über professionelle Secrets-Verwaltung nachdenken.

Die wichtigsten Regeln sind: Keine Secrets im Code. Keine Secrets im Prompt. Keine universellen Admin-Tokens. Möglichst kurze Laufzeiten. Eine Identität pro Agent. Und immer nur die minimal notwendigen Rechte.

Vault und andere Secret Manager lösen dabei nicht nur das Problem der sicheren Speicherung. Sie ermöglichen zentrale Zugriffskontrolle, Rotation, Auditierung und teilweise dynamisch erzeugte Zugangsdaten.

Gerade bei autonomen KI-Agenten ist das entscheidend.

Denn die Frage sollte nicht lauten: „Wo verstecke ich meinen API-Key vor dem Agenten?"

Sondern: „Warum sollte dieser Agent den API-Key überhaupt sehen müssen?"

Wer seine Architektur nach diesem Prinzip aufbaut, reduziert das Risiko kompromittierter Credentials erheblich – und kann KI-Agenten wesentlich kontrollierter in produktiven IT-Umgebungen einsetzen.

FAQ: API-Keys und KI-Agenten

Ist eine .env-Datei sicher?

Für lokale Entwicklungsumgebungen kann eine .env-Datei eine sinnvolle Lösung sein, wenn sie nicht in Git eingecheckt wird und restriktive Dateiberechtigungen besitzt. Für kritische Produktionsumgebungen sollte jedoch ein dediziertes Secrets-Management-System bevorzugt werden.

Sollte ein KI-Agent direkten Zugriff auf API-Keys haben?

Wenn möglich, nein. Besser ist eine Architektur, bei der ein freigegebenes Tool oder ein MCP-Server die Authentifizierung übernimmt und der Agent lediglich die erlaubte Funktion aufruft.

Was ist besser: .env oder HashiCorp Vault?

.env ist einfach und eignet sich gut für lokale Entwicklung. Vault bietet zusätzlich zentrale Zugriffskontrolle, Policies, Auditierbarkeit, Rotation und dynamische Credentials und eignet sich deshalb wesentlich besser für komplexe oder produktive Infrastrukturen.

Was bedeutet Least Privilege bei KI-Agenten?

Ein Agent erhält ausschließlich die Rechte, die er für seine konkrete Aufgabe benötigt. Ein Analyse-Agent benötigt beispielsweise normalerweise keine Löschrechte und ein Monitoring-Agent keine administrativen Datenbankrechte.

Was tun, wenn ein API-Key versehentlich veröffentlicht wurde?

Der Schlüssel sollte unverzüglich rotiert oder widerrufen werden. Danach sollten Repository-Historie, Logs, Agentenkontexte und Audit-Daten auf mögliche Nutzung beziehungsweise weitere Kopien des Secrets überprüft werden.

Sind Environment Variables für Secrets sicher?

Sie sind besser als fest im Quellcode eingebettete Zugangsdaten, stellen aber keinen vollwertigen Secret Store dar. Umgebungsvariablen können unter bestimmten Umständen beispielsweise über Debugging, Logs oder Diagnosedaten offengelegt werden. OWASP empfiehlt deshalb für sensible Produktionsumgebungen geeignetere Secret-Management-Verfahren.

Quellen und fachliche Grundlage

Für die technischen Sicherheitsempfehlungen wurden unter anderem die aktuellen Dokumentationen und Empfehlungen von OWASP, HashiCorp Vault, GitHub Secret Scanning und Docker berücksichtigt. OWASP empfiehlt unter anderem Least Privilege, zentrale Secrets-Verwaltung, Rotation und die Vermeidung von Secrets in Logs. HashiCorp dokumentiert Policies, TTL-basierte Leases und dynamische Credentials; GitHub bietet Secret Scanning und Push Protection, während Docker für sensible Daten Secret-Mechanismen statt dauerhaft in Images gespeicherter ARG- oder ENV-Werte empfiehlt.

Stand der technischen Prüfung: 17. September 2026.

Weiterführende Themen und Quellen

Welche Rechte darf ein KI-Agent bekommen? Sicherheitsregeln für Agenten (Zum Artikel)

MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel)

Eigenen MCP Server erstellen: Architektur und Praxisbeispiel (Zum Artikel)

Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel)

Shadow AI verhindern: Technische und organisatorische Maßnahmen (Zum Artikel)

KI-Richtlinie fürs Unternehmen: Was Mitarbeiter dürfen – und was nicht (Zum Artikel)

AGENTS.md vs. CLAUDE.md: Welche Datei braucht dein Projekt? (Zum Artikel)