MLflow's agent tracing quietly copied CrewAI agents' LLM API keys into its trace logs

Nobody wrote code to log the API key. The monitoring tool did it for them.

What happened

MLflow is a popular open-source platform that, among other things, records what an AI agent does, step by step, so developers can debug it later. Those records are called traces. MLflow has a one-line switch for CrewAI agents, mlflow.crewai.autolog(), that turns tracing on automatically.

With that switch on, MLflow's trace of the agent also contained the API key the agent uses to call its model provider, such as OpenAI or Anthropic. The key landed in plaintext in the MLflow tracking backend, and in any other system the traces were exported to over OTLP. The issue is now tracked as CVE-2026-116691 and rated medium severity. It affects MLflow from version 2.19.0 and was fixed in 3.17.0.

How it went wrong

According to MLflow's security advisory, the autologging code walked the CrewAI Agent object's internal fields and turned them into strings. One of those fields holds the agent's LLM object, and in CrewAI 1.15.18 that object's text form includes its api_key in plain sight. MLflow then saved the whole string as a span attribute.

The awkward part: MLflow's dedicated code for recording LLM details already left api_key out on purpose. The broader agent serialization simply went around that protection. A second, separate code path that records a call's inputs expanded the Agent object the same way, so the key leaked through two independent routes. The advisory says a test on MLflow 3.16.0 with CrewAI 1.15.18 found a fake key in five attribute locations across two spans.

What MLflow says to do

Upgrade to MLflow 3.17.0 or later. Then rotate any LLM provider key that a CrewAI LLM object held while autologging was on with MLflow 2.19.0 through 3.16.x, because upgrading stops new leaks but does not remove keys already written. Finally, delete or redact the affected traces in the MLflow tracking backend and in every OTLP destination they were exported to. If you can't upgrade yet, the advisory's workaround is to switch CrewAI autologging off.

Our take

This is our opinion: observability is a data pipeline, and pipelines copy things. Any tool that serializes whole objects will eventually serialize a secret. Treat trace stores like production databases, with access controls and retention limits, and test your agent with fake planted keys to see where they turn up. Better still, keep long-lived provider keys out of agent objects entirely and inject short-lived ones at call time.

Lesson for builders

Your agent's logs are only as safe as the most careless object they serialize. Scan traces for secrets before you ship them anywhere.