Gate sensitive data collection in AgentFrameworkInstrumentor behind environment variable

[Copilot]

AgentFrameworkInstrumentor was calling enable_instrumentation() without forwarding the user's sensitive-data preference, so the Agent Framework SDK would default to suppressing sensitive span attributes.

Changes

• _trace_instrumentor.py: Read the AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED environment variable (the same variable used by the Agent Framework SDK) and pass its parsed boolean value as enable_sensitive_data to enable_instrumentation(). Defaults to False when the variable is unset.
• Updated docstring to document the environment variable and its effect on sensitive data (prompts, tool arguments, results) in emitted spans.

# Before
enable_instrumentation()

# After
enable_sensitive_data = os.environ.get("AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED", "").strip().lower() in ("true", "1", "yes", "on")
enable_instrumentation(enable_sensitive_data=enable_sensitive_data)

• tests/agent_framework/test_trace_instrumentor.py: Updated existing test to assert enable_sensitive_data=False is passed when the env var is unset. Added two new tests:
  • test_instrument_enables_sensitive_data_when_env_var_set: asserts enable_sensitive_data=True when AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED=true
  • test_instrument_disables_sensitive_data_when_env_var_false: asserts enable_sensitive_data=False when the env var is explicitly false

[Copilot]

Pull request overview

This PR changes the Agent Framework instrumentor so the distro explicitly opts into sensitive span attributes from the Agent Framework SDK. In this codebase, that affects the built-in Agent Framework auto-instrumentation path used when A365 instrumentation is enabled.

Changes:

• Updated AgentFrameworkInstrumentor to call enable_instrumentation(enable_sensitive_data=True).
• Revised the instrumentor docstring to describe the new call signature.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rads-1996]

Valid comment. Please add a test to validate the new behavior.

[singankit]

@copilot

[Copilot]

Added tests in commit 07f3ac1:

• test_instrument_calls_enable_instrumentation_when_available now asserts enable_instrumentation(enable_sensitive_data=False) when the env var is unset
• test_instrument_enables_sensitive_data_when_env_var_set asserts enable_sensitive_data=True when AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED=true
• test_instrument_disables_sensitive_data_when_env_var_false asserts enable_sensitive_data=False when the env var is explicitly false

[rads-1996]

Instead of always passing in the variable to be true, we could probably read the value from the env variable, the way it is in agent framework. If the variable is not set the default value is False.

[singankit]

Without enabling_sensitive_data traces are not really helpful so would like it to be enabled by default

[Copilot]

Done in commit 07f3ac1. enable_sensitive_data is now derived from the AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED environment variable (the same one used by the Agent Framework SDK), defaulting to False when unset. Truthy values are true, 1, yes, on.

[mattmccleary]

Questions:

• What sensitive data is gated?
• Does this apply to Distro too? Why or why not?
• Is this coordinated with what Priyanka/Pipeline is doing? Two layer protection?
• How do customers extend / add their own rules?
• Is there a way this could be done across all instrumentation libraries to scale better?