Security: Unfiltered **kwargs in registry.create_llm could allow API key override #10534

New issue

Open

opened 2026-04-18 17:07:05 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-18 17:07:05 +00:00

Owner

Metadata

Commit: HEAD
Branch: main

Background and Context

In src/cleveragents/providers/registry.py, the create_llm() method accepts arbitrary **kwargs and passes them directly to the LLM constructor without any validation or filtering. This creates a security vulnerability where callers can override sensitive parameters like API keys, endpoints, and other critical configuration.

The vulnerable code path:

def create_llm(
    self,
    provider_type: ProviderType | str | None = None,
    model_id: str | None = None,
    **kwargs: object,
) -> BaseLanguageModel:
    ...
    return self._create_provider_llm(provider_type, model_id, **kwargs)

And in _create_provider_llm():

return ChatOpenAI(model=model_id or "gpt-4o", **kwargs)

Expected Behavior

The create_llm() method should:

Define an explicit whitelist of allowed parameters that can be passed to the LLM constructor
Reject or filter out any kwargs that could override sensitive parameters (api_key, azure_endpoint, base_url, etc.)
Raise a clear error if a caller attempts to pass disallowed parameters
Document which parameters are safe to pass through

Actual Behavior

Arbitrary kwargs are passed through to the LLM constructor without validation, allowing a caller to:

Call registry.create_llm(provider_type="openai", api_key="fake_key")
The returned LLM instance will use the fake API key instead of the configured one
This could cause requests to be sent with invalid credentials or to attacker-controlled endpoints

Acceptance Criteria

Identify all sensitive parameters that should NOT be overridable (api_key, azure_endpoint, base_url, api_version, etc.)
Implement a whitelist of allowed kwargs in create_llm() and _create_provider_llm()
Add validation to reject disallowed parameters with a clear error message
Add unit tests verifying that sensitive parameters cannot be overridden
Add unit tests verifying that allowed parameters can still be passed through
Update docstrings to document which parameters are allowed
Verify all LLM provider implementations (OpenAI, Azure, Anthropic, etc.) are protected

Subtasks

Audit registry.py to identify all sensitive parameters across different LLM providers
Create a whitelist of safe, allowed parameters
Implement parameter validation in create_llm() method
Implement parameter validation in _create_provider_llm() method
Write unit tests for parameter filtering
Update method docstrings with allowed parameters
Test with all supported LLM providers
Document the security fix in release notes

Definition of Done

This issue should be closed when:

All sensitive parameters are filtered and cannot be overridden via kwargs
Unit tests confirm that sensitive parameters are rejected with appropriate errors
Unit tests confirm that safe parameters can still be passed through
Code review has verified the fix is comprehensive across all provider implementations
Documentation has been updated to reflect the allowed parameters

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata - **Commit:** HEAD - **Branch:** main ## Background and Context In `src/cleveragents/providers/registry.py`, the `create_llm()` method accepts arbitrary **kwargs and passes them directly to the LLM constructor without any validation or filtering. This creates a security vulnerability where callers can override sensitive parameters like API keys, endpoints, and other critical configuration. The vulnerable code path: ```python def create_llm( self, provider_type: ProviderType | str | None = None, model_id: str | None = None, **kwargs: object, ) -> BaseLanguageModel: ... return self._create_provider_llm(provider_type, model_id, **kwargs) ``` And in `_create_provider_llm()`: ```python return ChatOpenAI(model=model_id or "gpt-4o", **kwargs) ``` ## Expected Behavior The `create_llm()` method should: 1. Define an explicit whitelist of allowed parameters that can be passed to the LLM constructor 2. Reject or filter out any kwargs that could override sensitive parameters (api_key, azure_endpoint, base_url, etc.) 3. Raise a clear error if a caller attempts to pass disallowed parameters 4. Document which parameters are safe to pass through ## Actual Behavior Arbitrary kwargs are passed through to the LLM constructor without validation, allowing a caller to: 1. Call `registry.create_llm(provider_type="openai", api_key="fake_key")` 2. The returned LLM instance will use the fake API key instead of the configured one 3. This could cause requests to be sent with invalid credentials or to attacker-controlled endpoints ## Acceptance Criteria - [ ] Identify all sensitive parameters that should NOT be overridable (api_key, azure_endpoint, base_url, api_version, etc.) - [ ] Implement a whitelist of allowed kwargs in `create_llm()` and `_create_provider_llm()` - [ ] Add validation to reject disallowed parameters with a clear error message - [ ] Add unit tests verifying that sensitive parameters cannot be overridden - [ ] Add unit tests verifying that allowed parameters can still be passed through - [ ] Update docstrings to document which parameters are allowed - [ ] Verify all LLM provider implementations (OpenAI, Azure, Anthropic, etc.) are protected ## Subtasks - [ ] Audit `registry.py` to identify all sensitive parameters across different LLM providers - [ ] Create a whitelist of safe, allowed parameters - [ ] Implement parameter validation in `create_llm()` method - [ ] Implement parameter validation in `_create_provider_llm()` method - [ ] Write unit tests for parameter filtering - [ ] Update method docstrings with allowed parameters - [ ] Test with all supported LLM providers - [ ] Document the security fix in release notes ## Definition of Done This issue should be closed when: 1. All sensitive parameters are filtered and cannot be overridden via kwargs 2. Unit tests confirm that sensitive parameters are rejected with appropriate errors 3. Unit tests confirm that safe parameters can still be passed through 4. Code review has verified the fix is comprehensive across all provider implementations 5. Documentation has been updated to reflect the allowed parameters --- **Automated by CleverAgents Bot** Agent: new-issue-creator

HAL9000 added the

labels

2026-04-18 17:08:02 +00:00