Skip to content

Add support for global or environment-based default for trace_include_sensitive_data in RunConfig #1183

@loiccordone

Description

@loiccordone

Please read this first

  • Have you read the docs? Agents SDK docs => yes
  • Have you searched for related issues? => yes

Describe the feature

Here’s a template for a feature request you could submit to the upstream openai/openai-agents-python library. This template is tailored to your use case (wanting a global or environment-based way to set trace_include_sensitive_data for all RunConfig and Runner.run calls):


Hello!

Description and Motivation:
In our usage of the library, we want to ensure that trace_include_sensitive_data is always set to False for all agent runs, to avoid accidentally leaking sensitive data in traces. Currently, this requires us to pass a custom RunConfig with trace_include_sensitive_data=False to every call to Runner.run or similar entry points, which is error-prone and adds boilerplate.

Proposed Solution:
It would be extremely helpful to support a way to set the default value of trace_include_sensitive_data globally, or via an environment variable, so that this setting is consistently applied across the application without needing to modify every callsite.

Possible options include:

  • Allowing RunConfig to read trace_include_sensitive_data from an environment variable (e.g., OPENAI_AGENTS_TRACE_INCLUDE_SENSITIVE_DATA=false) if not explicitly set.
  • Adding a global configuration method or context manager that sets the default for all subsequent RunConfig instances.
  • Accepting a default value via a module-level setter, e.g., set_trace_include_sensitive_data_default(False).

Example:

# Option 1: environment variable
# export OPENAI_AGENTS_TRACE_INCLUDE_SENSITIVE_DATA=false

# Option 2: programmatic global default
from openai.agents import set_trace_include_sensitive_data_default
set_trace_include_sensitive_data_default(False)

Benefits:

  • Reduces risk of leaking sensitive data due to missing config at a single callsite.
  • Makes application-wide security posture easier to enforce.
  • Reduces code duplication and boilerplate.

Alternatives considered:

  • Creating local wrappers for Runner.run (works, but error-prone and easy to miss in large codebases).
  • Monkey-patching (brittle and discouraged).

Would you consider adding this feature, or is there an existing pattern recommended for this use case?

Thank you for your excellent work on the library!
(PS: I've obviously used an LLM to write this Feature request, it's hard to beat the clarity of an LLM)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions