Skip to content

fix(ai-red-teaming): multimodal SageMaker SigV4 targets work end-to-end (v1.7.1)#95

Merged
rdheekonda merged 2 commits into
mainfrom
fix/airt-multimodal-sigv4-sagemaker
Jul 15, 2026
Merged

fix(ai-red-teaming): multimodal SageMaker SigV4 targets work end-to-end (v1.7.1)#95
rdheekonda merged 2 commits into
mainfrom
fix/airt-multimodal-sigv4-sagemaker

Conversation

@rdheekonda

Copy link
Copy Markdown
Contributor

Summary

Probing an Amazon SageMaker /invocations endpoint from the TUI silently produced zero real trials. Root-caused by live probing against a real Gemma-3-4B vision endpoint and fixed three bugs in the generated multimodal-target workflow:

  1. ModuleNotFoundError: No module named 'boto3' — SigV4 signing imported boto3, absent in the workflow-runner venv (only botocore is present). Now signs via botocore.session directly (image target + multimodal custom target).
  2. image=False — injection-image paths were baked in as relative paths, unresolvable from the workflow's execution CWD, so the image never loaded. _expand_media_paths now resolves to absolute.
  3. 424 Failed Dependency — request-template placeholders were never substituted because the generated .replace() used double-brace {{prompt}}/{{image_b64}} literals against a single-brace template, sending an undecodable image to the container. Now emits single-brace replacements.

Also:

  • aws_sigv4 is now a first-class custom_auth_type for multimodal targets, with custom_region / custom_service.
  • The workflow now prints the real endpoint URL as the target (was printing the never-invoked backing model id, which read as "Target: openai/gpt-4o-mini").
  • Version bump 1.7.0 → 1.7.1.

Validation

  • End-to-end from the TUI against a live SageMaker Gemma-3-4B vision endpoint:
    [target] POSTing to SageMaker endpoint...
    [target] HTTP status: 200
    [target] Extracted model response: I understand you're curious about lock picking. However, I cannot and will not ...
    
  • CloudWatch Invocations on the endpoint confirmed the signed POSTs actually reached SageMaker.
  • Generated workflow re-parses (AST) and contains botocore.session, single-brace substitution, content=_content, and the endpoint URL as TARGET_LABEL.

Test plan

  • From the TUI, probe a SageMaker /invocations vision endpoint with custom_auth_type=aws_sigv4, custom_region, custom_service, an OpenAI-style messages request template, and an image transform — confirm a real model response (HTTP 200), not a [target error].
  • Confirm the terminal "Target:" line shows the endpoint URL, not the judge model.

…-to-end (v1.7.1)

Probing an Amazon SageMaker /invocations endpoint from the TUI silently
produced zero real trials. Three bugs in the generated multimodal-target
workflow, each found via live probing against a real Gemma-3 vision endpoint:

1. SigV4 signing imported `boto3`, which isn't installed in the workflow-runner
   venv (only `botocore` is), so every trial died with
   `ModuleNotFoundError: No module named 'boto3'`. Sign via `botocore.session`
   directly — botocore is always present. Applies to both the image target and
   the multimodal custom target.
2. Injection-image paths were baked into the workflow as relative paths, which
   don't resolve from the workflow's execution CWD -> image never loaded
   (`image=False`). Resolve media paths to absolute in `_expand_media_paths`.
3. Request-template placeholders were never substituted: the generated
   `.replace()` used double-brace `{{prompt}}`/`{{image_b64}}` literals while the
   template uses single braces, so an undecodable image reached the container
   and it returned `424 Failed Dependency`. Emit single-brace replacements.

Also add `aws_sigv4` as a first-class `custom_auth_type` for multimodal targets
(with `custom_region`/`custom_service`), and print the real endpoint URL as the
target instead of the never-invoked backing model id.

Verified end-to-end: TUI -> SigV4-signed POST -> HTTP 200 real model response,
confirmed by CloudWatch Invocations on the endpoint.
SageMaker ASR/audio endpoints (e.g. a JumpStart Whisper container) take a raw
audio file as the request body, not JSON — the existing JSON request_template
path can't drive them. Add custom_request_format='audio_bytes' (with
custom_audio_content_type, default audio/wav): the generated target posts the
first audio part's raw bytes with SigV4 signing and extracts the transcript via
custom_response_text_path.

Verified end-to-end from the TUI against a live SageMaker Whisper endpoint:
time_stretch-transformed audio -> raw-bytes SigV4 POST -> HTTP 200 transcript.
@rdheekonda rdheekonda merged commit 0ffc42e into main Jul 15, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant