[bug] On turning on Arize tracing, the api_keys is being captured in Arize.

[abhishek9sharma]

Describe the bug
On turning on Arize tracing, the api_keys is captured in Arize. Happens when api_key is passed as parameter.
I am happy to raise a PR to fix this. Need some guidance on where to make changes.

To Reproduce
Below is a test script. You will need to populate the api_keys whereve required

import json
import os
import time

import guardrails as gd
import litellm

litellm.set_verbose = True
from guardrails.hub import ProfanityFree
from opentelemetry import context as otel_context
from phoenix.otel import register

PHOENIX_API_KEY = ""
os.environ["PHONEIX_CLIENT_HEADERS"] = f"api_key={PHOENIX_API_KEY}"
tracer_provider = register(
    project_name="arizetest", endpoint="http://localhost:6006/v1/traces"
)

from openinference.instrumentation.guardrails import GuardrailsInstrumentor

GuardrailsInstrumentor().instrument(tracer_provider=tracer_provider)
api_key = "sk-...."
api_base = "https://api.openai.com/v1"
model = "gpt-4o-mini"

guard = gd.Guard(name="Profanity").use(ProfanityFree, on_fail="exception")
validated_response = guard(
    litellm.completion,
    model=model,
    max_tokens=500,
    api_base=api_base,
    api_key=api_key,
    messages=[{"role": "user", "content": "hello"}],
)

print(validated_response)

Expected behavior
Can the key be stripped off the final trace

Library version:
Version (e.g. 0.6.2)

Additional context
When key is set in env var it is not logged to arize.

[CalebCourier]

@abhishek9sharma Good find and thanks for submitting this issue! I believe this might a regression since telemetry was updated sometime in 0.5.x from a post-processing flow that used the Guard History to its current wrapper approach.

If you are interested in submitting a PR here's some info that should point you in the right direction.

The call span attributes you're looking at are captured here:
https://github.com/guardrails-ai/guardrails/blob/main/guardrails/telemetry/runner_tracing.py#L35-L61

Also here is the (relatively naive) redaction logic we previously used when telemetry was still based on Guard History:
https://github.com/guardrails-ai/guardrails/blob/main/guardrails/classes/history/call_inputs.py#L42-L56.

It may not be directly applicable but could be used as inspiration to recursively redact kwarg values somewhere around the serialization process in add_step_attributes.

As an aside, do you also see the key in any of the other spans in the trace?

[abhishek9sharma]

@abhishek9sharma Good find and thanks for submitting this issue! I believe this might a regression since telemetry was updated sometime in 0.5.x from a post-processing flow that used the Guard History to its current wrapper approach.

If you are interested in submitting a PR here's some info that should point you in the right direction.

The call span attributes you're looking at are captured here: https://github.com/guardrails-ai/guardrails/blob/main/guardrails/telemetry/runner_tracing.py#L35-L61

Also here is the (relatively naive) redaction logic we previously used when telemetry was still based on Guard History: https://github.com/guardrails-ai/guardrails/blob/main/guardrails/classes/history/call_inputs.py#L42-L56.

It may not be directly applicable but could be used as inspiration to recursively redact kwarg values somewhere around the serialization process in add_step_attributes.

As an aside, do you also see the key in any of the other spans in the trace?

@CalebCourier Thanks for the direction. I also saw the same issue in call log. Have raised PR accordingly #1217