API Key Management in Kiro
Kiro provides three distinct mechanisms to handle API keys securely — depending on whether you need them for MCP servers, the Autonomous Agent sandbox, or your own application code.
1. MCP Server Environment Variables
MCP servers receive API keys through environment variable references in .kiro/settings/mcp.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
On first use, Kiro shows an approval popup. Only explicitly approved variables are expanded (manage them via Settings → "Mcp Approved Env Vars"). In the CLI, the variable must be exported in the shell beforehand.
Load Priority
Highest to lowest: Agent config (mcpServers field) > Workspace .kiro/settings/mcp.json > Global ~/.kiro/settings/mcp.json. Same server name = full override by the higher level; different names = additive.
Changes to mcp.json apply automatically on save (Cmd/Ctrl+S) — no session restart, no loss of conversation context. Only changed servers reconnect; reordering keys does not trigger a restart.
Remote MCP Servers & OAuth
Besides local (stdio) servers, Kiro supports remote servers over HTTPS. Instead of command/args, they use:
| Field | Description |
|---|---|
url | HTTPS endpoint (HTTP only for localhost) |
headers | Additional HTTP headers (e.g. API keys via ${VAR}) |
oauth | OAuth config (clientId, clientSecret, redirectUri, oauthScopes, ...) |
oauthScopes | Fallback scopes (overridden by oauth.oauthScopes) |
disabled | Disable the server |
autoApprove | Tools without manual confirmation |
disabledTools | Tools not offered to the agent |
Kiro runs the browser-based OAuth flow automatically. Servers with Dynamic Client Registration (DCR, RFC 7591) need no extra config — just connect. On token expiry without a refresh token, Kiro starts a new flow; the MCP panel shows a re-authenticate button.
Important (IDE vs. CLI): The IDE supports only public OAuth clients (PKCE without client_secret). Services requiring a client_secret (e.g. Figma) work only via the CLI (confidential clients).
{
"mcpServers": {
"remote-api": {
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${API_TOKEN}" },
"disabledTools": ["delete_resource"]
}
}
}
2. Autonomous Agent Sandbox Secrets
For the Autonomous Agent, store secrets via Autonomous Agent → Sandbox → Secrets in the Kiro UI.
- Secrets are encrypted at rest
- Only available during task execution inside the isolated sandbox
- Not accessible to MCP servers or the main IDE process
3. Application .env Files
For your own application code, use standard .env files with your framework’s loader (dotenv, Vite, etc.).
- Add
.envto.gitignore - Provide a
.env.examplewith placeholder values - Kiro can read .env for context but never commits secrets
Security Best Practices
Key Recommendations
- Never hardcode API keys in source files
- Add
.kiro/settings/mcp.jsonto.gitignore - Create tokens with minimal permissions (least privilege)
- Rotate keys regularly
- Only set
autoApprovefor read-only tools - Use Enterprise governance to manage allowed API keys centrally
Frequently Asked Questions
How do you pass API keys to MCP servers in Kiro?
Use environment variable references with ${VARIABLE_NAME} in mcp.json. Kiro only expands approved variables – an approval popup appears on first use.
Where do you store secrets for the Autonomous Agent?
Via the Kiro UI under Autonomous Agent → Sandbox → Secrets. Secrets are stored encrypted and only provided during task execution.
Should you commit mcp.json to Git?
No. The .kiro/settings/mcp.json should be in .gitignore since it contains variable references. Use minimal-permission tokens and rotate regularly.