AI and data stack advisories

Severe, 6 weeks2048Projects319

2048 severe, 6 weeks · 319 projects

pydantic-aiGHSA-4x9p-g9wm-8q7f

pydantic-ai: secrets in logs

pydantic-ai

CVE-2026-107291 · Published Oct 8, 2026

Low
Fix: upgrade to 1.107.6 or later (2 fixed versions below)
GitHub advisory

Summary

Pydantic AI's OpenTelemetry instrumentation supports InstrumentationSettings(include_content=False) to exclude message content , user prompts, model completions, tool call arguments and responses, and any other message content , from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.

The message attributes honoured the setting. Several other parts of the same spans did not, and exported content regardless of it:

  • Exceptions. Recorded as OpenTelemetry exception events, with their message and stack trace, on tool, agent run, model request, embedding and image generation spans, and on realtime session spans. The message of the exception carrying a tool's ModelRetry or ToolFailed feedback is the text sent back to the model, which can quote tool arguments and results. When a tool ran out of retries, the error that ended the run was chained from the last retry, so its stack trace repeated that text on the run span. Exceptions raised by tool code were recorded with their full message, as were failures of a model request, embedding or image generation, whose messages carry the provider's error response body.
  • The error status description. The OpenTelemetry SDK describes a span's ERROR status with the exception's type and message, so the message reached the backend a second time even where...

Affected versions

PackageAffectedFixed in
pydantic-ai
PyPI
>= 0.3.4, < 1.107.61.107.6
>= 2.0.0b1, < 2.44.02.44.0
Details and references

### Summary Pydantic AI's OpenTelemetry instrumentation supports `InstrumentationSettings(include_content=False)` to exclude message content , user prompts, model completions, tool call arguments and responses, and any other message content , from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend. The message attributes honoured the setting. Several other parts of the same spans did not, and exported content regardless of it: - **Exceptions.** Recorded as OpenTelemetry exception events, with their message and stack trace, on tool, agent run, model request, embedding and image generation spans, and on realtime session spans. The message of the exception carrying a tool's `ModelRetry` or `ToolFailed` feedback is the text sent back to the model, which can quote tool arguments and results. When a tool ran out of retries, the error that ended the run was chained from the last retry, so its stack trace repeated that text on the run span. Exceptions raised by tool code were recorded with their full message, as were failures of a model request, embedding or image generation, whose messages carry the provider's error response body. - **The error status description.** The OpenTelemetry SDK describes a span's ERROR status with the exception's type and message, so the message reached the backend a second time even where the event itself was redacted. - **Instructions and the prompted-output template.** The `model_request_parameters` attribute serialized the request's instruction parts in full, exporting the agent's instructions , both static and those built from dependencies at request time , along with the template used to prompt for structured output. ### Details Content reaches these places because of what they carry rather than through any single missing check, which is why the setting was applied correctly to the message attributes (`gen_ai.input.messages`, `gen_ai.tool.call.arguments`, `gen_ai.tool.call.result`, and so on) while these paths were not: the exception recording and the status description came from the OpenTelemetry SDK's defaults, and the instructions and output template were serialized as part of the request's parameters rather than treated as content. ### Impact This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data , a third-party observability vendor or a shared backend , which is the scenario `include_content=False` exists for. ### Who Is Affected You are affected if you enabled instrumentation with `include_content=False`. Instructions are exported on every successful run, so no failure is needed to be affected; the exception paths additionally require a tool to raise, or a model, embedding or image generation request to fail. Realtime sessions are affected the same way, through the errors their provider connections report. GHSA-3gh4-cghq-f8v4 stated that retries coming from tool calls were redacted correctly; that was true of the retry prompt in the message attributes but not of the exception event on the tool span. You are not affected if you don't set `include_content=False`. ### Remediation Upgrade to a patched version. With `include_content=False`, exception events now record only the exception type, error statuses carry no description, and `model_request_parameters` is exported without its instruction content or output template. If you rely on this setting, consider reviewing previously exported traces for exception events, for error status descriptions, and for `model_request_parameters`. ### Workaround for Unpatched Versions If you cannot upgrade, scrub the `exception.message` and `exception.stacktrace` event attributes, the error status description, and the instruction parts and `prompted_output_template`

CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Severity from
GitHub (reviewed advisory)
Weakness
CWE-212, CWE-532
Also known as
CVE-2026-107291

More pydantic-ai advisories

All pydantic-ai