CVE-2026-116691

### Summary `mlflow.crewai.autolog()` leaks CrewAI LLM provider API keys into MLflow trace telemetry. When a CrewAI `Agent` is instrumented with MLflow autologging, MLflow serializes the agent's `__dict__` and converts its fields to strings. The `llm` field contains the CrewAI LLM object, whose string representation includes its `api_key` in plaintext. As a result, an application that calls `mlflow.crewai.autolog()` can unintentionally send its LLM provider API key to the MLflow trace backend or configured OTLP destination. The application does not need to explicitly log the credential or place it in a span attribute. The credential is extracted automatically by MLflow's instrumentation. This was verified on **MLflow 3.16.0** with **CrewAI 1.15.18** using MLflow's own OTLP exporter. The fake credential appeared in **5 attribute locations across 2 spans**. ### Details The primary issue is in: `mlflow/crewai/autolog.py::_get_agent_attributes()` The function walks the CrewAI `Agent.__dict__` and converts agent fields to strings. `tools` and `embedder` receive special handling, but credential-bearing objects such as the following are not sanitized: * `llm` * `function_calling_llm` * `agent_executor` * `crew` For example, `agent.llm` is a CrewAI `LLM` object. In CrewAI 1.15.18, the underlying LLM model contains `api_key` as a normal field. Its string representation therefore contains the credential: ```text llm_type='openai' model='gpt-4.1-mini' ... api_key='sk-proj-...' ... ``` MLflow subsequently stores this string as a span attribute. There is an important indication that this is an unintended disclosure: MLflow's dedicated LLM attribute extraction already explicitly excludes `api_key` in `_get_llm_attributes()`. The LLM span therefore does not expose the credential, while the broader Agent `__dict__` serialization bypasses that protection. There is also a second, independent serialization path in: `mlflow/crewai/autolog.py::_construct_full_inputs()`