Critical Security/UX Issue: API Key Leaks in Error Logs & Insecure Bootstrapping Workflow

[fodurrr]

🚨 Critical Security/UX Issue: API Key Leaks in Error Logs & Insecure Bootstrapping Workflow

1. The Problem

Severity: Critical
Component: Configuration / Error Handling

There are two linked critical failures in the current onboarding and configuration process:

1. Plain Text Key Exposure in Logs: If a user attempts to configure the agent or encounters an error during the initial handshake (e.g., passing a key as an argument or having a configuration error), the system's exception handler catches the input and echoes the raw API key in plain text into the chat logs/console. This is a massive security vulnerability.
2. Contradictory Security Model: The system forces users to store plain text API keys in the main Settings panel to "bootstrap" the system (initialize LiteLLM), while simultaneously telling them to use the Secret Store for safety. This forces the user to violate security best practices immediately upon onboarding.

2. User Impact

• Immediate Trust Loss: New users see their private credentials splashed across the screen in error logs within minutes of using the software.
• Confusion: The distinction between "Settings (Startup)" and "Secrets (Runtime)" is opaque. Users expect the §§secret() syntax to work everywhere.
• "Catch-22" Frustration: Users cannot use the secure method (Secret Store) because the system requires the insecure method (Plain Text) to start the engine that reads the secure store.

3. Proposed Solution: Secure Bootstrapping Workflow

We propose a new architectural flow to eliminate the permanent storage of plain text keys in the UI and prevent leaks.

The "One-Time Setup" Workflow

1. Initial Setup: User enters the plain text key once during the first run/setup.
2. System Bootstrap: The system starts up, verifies the key, and immediately encrypts/moves it to the internal Secret Store.
3. Restart & Load: On every subsequent system boot:
   • Before any Agent/LLM is initialized, a new "Middleware/Loader" runs.
   • This loader reads the keys from the Secret Store.
   • It injects them into the system environment/configuration in memory.
   • Only then does the LLM/Agent initialize, using the injected values.
4. Cleanup: The user can now safely delete the plain text key from the visible Settings fields. The system continues to function by pulling credentials from the secure store at boot time.

4. Technical Requirements

• Middleware Layer: Introduce a configuration pre-processor that runs before litellm initialization.
• Secret Resolution: This layer must be able to resolve §§secret() placeholders (or a similar mechanism) from the agent.json/config files without requiring an active LLM.
• Error Sanitization: IMMEDIATE FIX REQUIRED: The global exception handler must be patched to sanitize/mask any string that looks like an API key (regex match) before printing it to logs or chat output.

---

This proposal addresses the root cause (architecture) and the symptom (leaks), ensuring users never have to choose between "working software" and "secure software."

[PaoloC68]

Agreed on the need for a stronger security model. While working on a related area — specifically, how third-party skills and tool calls can be vetted before execution — I've submitted #1106 which adds guard extension points to the existing extension system.

It doesn't address the API key leak directly (that's a separate fix in the error handler), but it does provide the plumbing for:

• Blocking tool calls before execution if a skill has been flagged by a security scanner
• Detecting prompt injection patterns before they reach the LLM
• Scanning skills at install time via a skill_install extension point

The implementation uses importlib.metadata entry points so third-party security packages (like Cisco AI Skill Scanner) can register guard handlers without modifying core code.

For the key leak issue specifically, a sanitization pass in the exception handler (as you proposed) would be the right minimal fix — regex-matching common key patterns and masking them before they hit the log output.