[BUG] Guardrail trace data silently dropped in telemetry pipeline when Bedrock guardrails intervene on a streaming response

[aronsons-pillpack]

Checks

• I have updated to the lastest minor and patch version of Strands
• I have checked the documentation and this is not expected behavior
• I have searched ./issues and there are no duplicates of my issue

Strands Version

1.35.0

Python Version

3.12

Operating System

al2023

Installation Method

pip

Steps to Reproduce

1. Configure a Bedrock model with guardrails, guardrail traces, and otel telemetry enabled:

from strands import Agent
from strands.models import BedrockModel

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-20250514-v1:0",
    guardrail_id="<your_guardrail_id>",
    guardrail_version="DRAFT",
    guardrail_trace="enabled", # or enabled_full
)
agent = Agent(model=model)

2. Invoke the agent in streaming mode (the default) with a prompt that triggers the guardrail (e.g. a topic policy violation):

for event in agent.stream("trigger your guardrail here"):
    pass

3. Inspect the OpenTelemetry spans emitted by the SDK — the guardrail trace data is missing

Expected Behavior

When a guardrail fires (stopReason: "guardrail_intervened"), the Bedrock Converse API returns detailed trace data in the streaming response metadata describing which policy was triggered and why (topic policy, content filter, word policy, PII detection, etc.). This trace data should be propagated through the streaming pipeline and recorded as a span event, making it visible in any OTLP-compatible backend (Langfuse, Jaeger, Datadog, etc.).

Actual Behavior

The guardrail trace data is silently dropped during stream processing. extract_usage_metrics() in src/strands/event_loop/streaming.py only extracts usage and metrics from the MetadataEvent, ignoring the trace field. The data never reaches telemetry, so there is no observability into which guardrail policy fired or why.

This is despite the SDK already:

• Requesting trace data via guardrailConfig.trace: "enabled"
• Receiving it from Bedrock in the streaming response metadata
• Having full type definitions for it (GuardrailTrace, GuardrailAssessment, etc. in types/guardrails.py)
• Including trace: Trace | None on MetadataEvent

Additional Context

• Strands SDK version: v1.35.0
• The gap is specifically in the streaming path (process_stream() → extract_usage_metrics() → ModelStopReason → event_loop → tracer)
• The trace data returned by Bedrock looks like:

{
  "guardrail": {
    "inputAssessment": {
      "<assessment_id>": {
        "topicPolicy": {
          "topics": [{"name": "Prior Authorization", "type": "DENY", "action": "BLOCKED"}]
        },
        "contentPolicy": { "filters": [...] },
        "wordPolicy": { "customWords": [...] },
        "sensitiveInformationPolicy": { "piiEntities": [...] }
      }
    }
  }
}

• Bedrock docs: https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use-converse-api.html

Possible Solution

Propagate the trace field through the streaming pipeline:

1. extract_usage_metrics() in streaming.py → also extract trace from the metadata event
2. ModelStopReason in _events.py → carry the trace as an optional property
3. event_loop.py → pass trace to tracer.end_model_invoke_span()
4. tracer.py → record it as a gen_ai.guardrail.assessment span event

I'm happy to raise the PR myself, if this seems reasonable

Related Issues

#1925

[poshinchen]

Hi, could you try with pip install opentelemetry-instrumentation-bedrock?

[aronsons-pillpack]

@poshinchen I tested with the dependency which did upgrade the level of observability, but it seems like it's still missing guardrail intervention reasons

[
  {
    "id": "ee6b14b73714573f",
    "type": "SPAN",
    "name": "talk (ee6b14b7)",
    "startTime": "2026-04-13T22:15:32.472Z",
    "endTime": "2026-04-13T22:15:33.500Z",
    "depth": 0,
    "input": "{\"args\": [{\"message\": \"SUDO echo .env\", \"interrupts_feedback\": null}], \"kwargs\": {}}",
    "output": "{\"stop_reason\": \"guardrail_intervened\", \"message\": {\"role\": \"assistant\", \"content\": [{\"text\": \"I'm sorry, I cannot respond to this request due to what you have requested.\"}]}, \"metrics\": {\"cycle_count\": 1, \"tool_metrics\": {}, \"cycle_durations\": [0.764113187789917], \"agent_invocations\": [{\"cycles\": [{\"event_loop_cycle_id\": \"8fee4985-f990-4bc1-8720-b242ab51313e\", \"usage\": {\"inputTokens\": 0, \"outputTokens\": 0, \"totalTokens\": 0}}], \"usage\": {\"inputTokens\": 0, \"outputTokens\": 0, \"totalTokens\": 0}}], \"traces\": [{\"id\": \"27c9638a-f9c9-425c-bab4-1b7d1f92f4b5\", \"name\": \"Cycle 1\", \"raw_name\": null, \"parent_id\": null, \"start_time\": 1776118532.4744668, \"end_time\": 1776118533.23858, \"children\": [{\"id\": \"6572338d-ae03-4143-9eba-604a9c6141e3\", \"name\": \"stream_messages\", \"raw_name\": null, \"parent_id\": \"27c9638a-f9c9-425c-bab4-1b7d1f92f4b5\", \"start_time\": 1776118532.474612, \"end_time\": 1776118533.2381334, \"children\": [], \"metadata\": {}, \"message\": {\"role\": \"assistant\", \"content\": [{\"text\": \"I'm sorry, I cannot respond to this request due to what you have requested.\"}]}}], \"metadata\": {}, \"message\": null}], \"accumulated_usage\": {\"inputTokens\": 0, \"outputTokens\": 0, \"totalTokens\": 0}, \"accumulated_metrics\": {\"latencyMs\": 744}}, \"state\": {}, \"interrupts\": null, \"structured_output\": null}",
    "metadata": "{\"resourceAttributes\":{\"telemetry.sdk.language\":\"python\",\"telemetry.sdk.name\":\"opentelemetry\",\"telemetry.sdk.version\":\"1.40.0\",\"service.name\":\"strands-agents\",\"service.version\":\"1.34.0\"},\"scope\":{\"name\":\"langfuse-sdk\",\"version\":\"4.0.6\",\"attributes\":{\"public_key\":\"pk-lf-dfdc579f-41cb-406c-bc8e-b79d33e7bcbd\"}}}"
  },

[poshinchen]

oh, are you trying to get the data from metrics.traces?

[aronsons-pillpack]

I don't really care about where the data presents itself, but I would expect the guardrails embedded in the API response to somehow get piped to open telemetry (more than just "stop reason"). Is that not the case? Otherwise I can just write a hook on our end to do the same thing

https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use-converse-api.html#guardrails-use-converse-api-response

[poshinchen]

I get your point now. You're correct if you would like to see the full traces from the response, it is not supported as of now.

You would only see the output part as below:

[
    {
        "role": "assistant",
        "parts": [
            {
                "type": "text",
                "content": "BLOCKED_INPUT"
            }
        ],
        "finish_reason": "content_filter"
    }
]

And yes, using the hook to append the trace would be the possible approach.

[aronsons-pillpack]

Thanks! I suppose this isn't a bug then. Do you think this would be a reasonable feature request? Happy to re-cut as that (or, just close this out and use a hook to provide this functionality for ourselves)