> ## Documentation Index
> Fetch the complete documentation index at: https://braintrust.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# LiteLLM instrumentation may record provider credentials

> Review common questions about the LiteLLM instrumentation security advisory, affected versions, credential exposure, and remediation.

export const plans_0 = "Any"

export const deployments_0 = "Any"

export const data_plane_version_0 = undefined

export const use_case_0 = "Use case - Understand and respond to the LiteLLM instrumentation security advisory"

<Note>
  **Applies to:**

  * Plan - {plans_0}
  * Deployment - {deployments_0}
  * {data_plane_version_0}
  * {use_case_0}
</Note>

## Summary

An implementation bug in Braintrust-maintained LiteLLM instrumentation could cause provider credentials passed directly to LiteLLM calls to be stored in Braintrust span metadata.

The [GitHub security advisory](https://github.com/braintrustdata/braintrust-sdk-python/security/advisories/GHSA-xwg7-7579-vg67) is the canonical source for affected versions, the trace detection query, workarounds, and technical references. This article answers common questions about the issue.

<Warning>
  If your application is affected, upgrade to `braintrust` v0.28.0 or later and rotate credentials that may have been recorded. Upgrading prevents affected fields from being recorded in new traces, but does not remove credentials from traces already stored.
</Warning>

## Frequently asked questions

### Was this a supply chain attack?

No. This was an implementation bug in Braintrust-maintained LiteLLM instrumentation. We found no compromise of the `braintrust` PyPI package, its build or publishing process, LiteLLM, or Braintrust systems.

### Which versions were affected?

The issue affected `braintrust` v0.2.0 to v0.27.x. It is fixed in `braintrust` v0.28.0 and later.

### Which instrumentation entry points were affected?

The affected paths were:

* `wrap_litellm()` beginning in `braintrust==0.2.0`.
* `patch_litellm()` beginning in `braintrust==0.3.5`.
* LiteLLM instrumentation through `auto_instrument()` beginning in `braintrust==0.5.2`.

An application may be affected when it used one of these entry points and passed credentials directly as keyword arguments to an instrumented LiteLLM call.

### What credentials could have been recorded?

Confirmed examples include:

* API keys.
* Authorization and API-key headers.
* Azure authentication tokens.
* AWS access keys, secret keys, and session tokens.
* Vertex AI credentials.

Other provider-specific secrets may also have been recorded because LiteLLM accepts arbitrary keyword arguments.

### Were credentials loaded from environment variables affected?

Credentials obtained by LiteLLM solely through environment variables, global LiteLLM configuration, or a cloud provider's default credential chain were not captured by this issue because they were not present in the instrumented call arguments.

### Were credentials sent anywhere other than Braintrust?

The instrumentation included the values in Braintrust span metadata. Normal provider requests were still sent to the provider selected through LiteLLM. We found no evidence that the issue transmitted credentials to any additional third party.

### How can I check for affected traces?

Follow [Check for affected traces](https://github.com/braintrustdata/braintrust-sdk-python/security/advisories/GHSA-xwg7-7579-vg67#check-for-affected-traces) in the GitHub security advisory. The query identifies common credential fields without returning their values.

Because LiteLLM supports arbitrary provider-specific keyword arguments, the absence of results does not rule out credentials passed through custom argument names.

### What changed in the fixed version?

The patched release records only an allowlist of known-safe LiteLLM request parameters. Credential fields, headers, transport configuration, and unknown provider-specific arguments are omitted from new span metadata by default.

### Does upgrading remove existing metadata?

No. Upgrading prevents affected fields from being recorded in new traces, but it does not modify traces already stored.

### What should I do if I find an affected trace?

Rotate the credential as soon as possible. Then review project access and upgrade every affected application to `braintrust` v0.28.0 or later.

### What can I do if I cannot upgrade immediately?

Follow the [workarounds in the GitHub security advisory](https://github.com/braintrustdata/braintrust-sdk-python/security/advisories/GHSA-xwg7-7579-vg67#workarounds). They include using environment-based authentication, configuring `braintrust.set_masking_function()`, or disabling LiteLLM instrumentation until you can upgrade.