From 589086dc5b812fdd34f2620ae2d653a31b3edab0 Mon Sep 17 00:00:00 2001
From: samtsai15 <6171228+samtsai15@users.noreply.github.com>
Date: Thu, 27 Aug 2026 09:57:27 +0800
Subject: [PATCH] fix(guardrails): carry Anthropic url and file image sources
 through to guardrails

_image_sources returned source["data"] only. An Anthropic image block has three
shapes (types/llms/anthropic.py:259) and only the base64 one carries "data", so
{"type": "url", "url": ...} yielded nothing and the image never reached any
guardrail at all.

This is not Bedrock-specific. Five guardrails consume
GenericGuardrailAPIInputs["images"] (vigil_guard, custom_code, deepkeep, straiker,
generic_guardrail_api) and every one of them was blind to url sources on
/v1/messages.

base64 now returns a data URI rather than the bare payload. A consumer otherwise
has no way to recover media_type, and an API like Bedrock's ApplyGuardrail needs
the format to build its request.

The file shape stays unresolvable here: the bytes live behind the Files API and
this extractor has no client to fetch them. Documented rather than silently
dropped, so a consumer treating a missing entry as "no image to scan" is a known
gap and not a surprise.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 .../chat/guardrail_translation/handler.py     | 32 +++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/litellm/llms/anthropic/chat/guardrail_translation/handler.py b/litellm/llms/anthropic/chat/guardrail_translation/handler.py
index 721a6653597..a09048be684 100644
--- a/litellm/llms/anthropic/chat/guardrail_translation/handler.py
+++ b/litellm/llms/anthropic/chat/guardrail_translation/handler.py
@@ -788,12 +788,40 @@ class AnthropicMessagesHandler(BaseTranslation):
 
     @staticmethod
     def _image_sources(block: Mapping[str, object]) -> tuple[str, ...]:
+        """Normalize an Anthropic image block into strings a guardrail can read.
+
+        `source` is one of three shapes (types/llms/anthropic.py:259):
+
+            {"type": "base64", "media_type": "image/png", "data": "<b64>"}
+            {"type": "url",    "url": "https://..."}
+            {"type": "file",   "file_id": "..."}
+
+        base64 is returned as a data URI rather than the bare payload: consumers of
+        ``GenericGuardrailAPIInputs["images"]`` otherwise have no way to know the
+        format, and an API like Bedrock's ApplyGuardrail requires it. url is passed
+        through so the consumer can fetch it under its own SSRF policy.
+
+        file is not resolvable here (the bytes live behind the Files API), so it
+        yields nothing. That is a silent gap for any consumer that treats a missing
+        entry as "no image to scan"; scanning a file_id needs a fetch this extractor
+        has no client for.
+        """
         source: Final = block.get("source")
         if not isinstance(source, Mapping):
             return ()
-        # Could be base64 or url
+
+        source_type: Final = source.get("type")
+        if source_type == "url":
+            url: Final = source.get("url")
+            return (url,) if isinstance(url, str) and url else ()
+
         data: Final = source.get("data")
-        return (data,) if data else ()
+        if not isinstance(data, str) or not data:
+            return ()
+        media_type: Final = source.get("media_type")
+        if isinstance(media_type, str) and media_type:
+            return (f"data:{media_type};base64,{data}",)
+        return (data,)
 
     async def _apply_guardrail_responses_to_input(
         self,