Wie übergibt man API-Keys an MCP-Server in Kiro?

In der mcp.json Umgebungsvariablen-Referenzen mit ${VARIABLE_NAME} nutzen. Die Variable wird in der Shell gesetzt (export auf Linux/macOS oder SetEnvironmentVariable auf Windows). Kiro expandiert nur genehmigte Variablen – beim ersten Mal erscheint ein Approval-Popup.

Wo speichert man Secrets für den Autonomous Agent?

Über die Kiro UI unter Autonomous Agent → Sandbox → Secrets. Secrets werden verschlüsselt gespeichert und nur während der Task-Ausführung als Umgebungsvariablen in der isolierten Sandbox bereitgestellt.

Sollte man mcp.json in Git committen?

Nein. Die .kiro/settings/mcp.json sollte in .gitignore stehen, da sie Variablen-Referenzen enthält. Tokens mit minimalen Rechten erstellen, regelmäßig rotieren und autoApprove nur für Read-Only-Tools setzen.

API-Keys in Kiro – Leadnet.de

Es gibt 3 Wege, API-Keys sicher zu übergeben — je nachdem, wer den Key braucht.

1. MCP-Server braucht den Key

GitHub Brave Search n8n Datenbanken

In der mcp.json verwendest du Umgebungsvariablen-Referenzen mit ${...}:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Dann setzt du die Variable in deiner Shell:

Linux / macOS

# In ~/.bashrc oder ~/.zshrc
export GITHUB_TOKEN=dein-token-hier

Windows (PowerShell, dauerhaft)

[Environment]::SetEnvironmentVariable("GITHUB_TOKEN", "dein-token-hier", "User")

⚡ Wichtig: Genehmigte Variablen

Kiro expandiert nur genehmigte Umgebungsvariablen. Beim ersten Mal zeigt Kiro ein Popup, das dich fragt, ob die Variable erlaubt werden soll. Du kannst das auch manuell verwalten unter:

Settings → "Mcp Approved Env Vars"

Speicherorte & Lade-Priorität der mcp.json

Priorität	Ebene	Pfad
1 (höchste)	Agent-Config	`mcpServers`-Feld im Agent-JSON
2	Workspace	`.kiro/settings/mcp.json`
3	User (global)	`~/.kiro/settings/mcp.json`

Gleicher Servername = kompletter Override durch höhere Ebene. Unterschiedliche Namen = additiv (alle laufen). disabled: true verhindert den Start.

🔄 Hot-Reload (neu)

Änderungen an der mcp.json greifen automatisch beim Speichern (Cmd/Strg+S) — ohne Session-Neustart und ohne Verlust des Konversationskontexts. Nur geänderte Server werden neu verbunden; unveränderte laufen weiter. Das reine Umsortieren von Keys triggert keinen Restart.

Remote MCP-Server & OAuth

Neben lokalen (stdio) Servern unterstützt Kiro Remote-Server über HTTPS. Statt command/args werden andere Felder genutzt:

Feld	Beschreibung
`url`	HTTPS-Endpoint (HTTP nur für localhost)
`headers`	Zusätzliche HTTP-Header (z.B. für API-Keys via `${VAR}`)
`oauth`	OAuth-Konfiguration (clientId, clientSecret, redirectUri, oauthScopes, ...)
`oauthScopes`	Fallback-Scopes (wird von `oauth.oauthScopes` überschrieben)
`disabled`	Server deaktivieren
`autoApprove`	Tools ohne manuelle Bestätigung
`disabledTools`	Tools, die dem Agent nicht angeboten werden

🔑 OAuth-Flow

Kiro führt den browser-basierten OAuth-Flow automatisch aus. Server mit Dynamic Client Registration (DCR, RFC 7591) brauchen keine Extra-Config — einfach verbinden. Bei ablaufenden Tokens ohne Refresh-Token startet Kiro automatisch einen neuen Flow; im MCP-Panel erscheint ein Re-Authenticate-Button.

Wichtig (IDE vs. CLI): Die IDE unterstützt nur public OAuth-Clients (PKCE ohne client_secret). Dienste, die ein client_secret verlangen (z.B. Figma), funktionieren nur über die CLI (confidential clients).

Beispiel: Remote-Server mit Header-Auth

{
  "mcpServers": {
    "remote-api": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${API_TOKEN}"
      },
      "disabledTools": ["delete_resource"]
    }
  }
}

disabledTools

Mit disabledTools lassen sich einzelne Tools eines Servers ausblenden — nützlich, um schreibende oder riskante Tools zu sperren, ohne den ganzen Server zu deaktivieren.

2. Autonomous Agent (Sandbox) braucht den Key

Für den autonomen Agenten gibt es einen eigenen Bereich in der Kiro-Oberfläche:

Environment Variables — für nicht-sensible Konfiguration
Secrets — für API-Keys, verschlüsselt gespeichert

Secrets werden verschlüsselt abgelegt und nur während der Task-Ausführung als Umgebungsvariablen in der isolierten Sandbox bereitgestellt.

⚠️ Sicherheitshinweis

Der Agent könnte Secrets über Code-Änderungen, Logs oder externe Requests exfiltrieren. Nur Secrets bereitstellen, die für die aktuelle Aufgabe nötig sind, und nur mit vertrauenswürdigen Repositories verwenden.

Konfigurierbar über: Kiro UI → Autonomous Agent → Sandbox → Environment Variables

Duplikate

Wenn derselbe Key sowohl als Environment Variable als auch als Secret existiert, hat die Environment Variable Vorrang.

3. Deine App / dein Workflow braucht den Key

Hier gelten Standard-Entwicklungspraktiken:

.env-Datei im Projekt (in .gitignore!)
Im Code: process.env.API_KEY
Kiro kann die .env lesen und im Code verwenden, wenn du es aufforderst

# .env (im Projektverzeichnis)
OPENAI_API_KEY=sk-...
N8N_WEBHOOK_URL=https://n8n.example.com/webhook/abc123
DATABASE_URL=postgresql://user:pass@localhost:5432/mydb

// Im Code
const apiKey = process.env.OPENAI_API_KEY;

Security Best Practices

Regel	Warum
`${VARIABLE}` statt Klartext in `mcp.json`	Key nicht im Dateisystem sichtbar
Nie `mcp.json` mit Secrets committen	Kein Leak ins Repo
Tokens mit minimalen Rechten erstellen	Blast Radius begrenzen
Keys regelmäßig rotieren	Kompromittierte Keys werden wertlos
`autoApprove` nur für Read-Only-Tools	Schreibende Tools immer manuell bestätigen
`chmod 600` auf Config-Dateien	Kein Zugriff durch andere User
`.kiro/settings/mcp.json` in `.gitignore`	Workspace-Config nicht ins Repo

Zusammenfassung

Wer braucht den Key?	Wo ablegen?
MCP-Server (GitHub, Brave, n8n, etc.)	`mcp.json` → `"env": {"KEY": "${SHELL_VAR}"}`
Autonomous Agent	Kiro UI → Sandbox → Secrets
Deine App (Backend, Workflow)	`.env`-Datei + `.gitignore`
Kiro IDE selbst (Chat-Modus)	Über MCP-Server oder Shell-Variable

Quellen: