Skip to content

fix(ai-red-teaming): route dn/* through proxy, keep local keys (ENG-7284)#66

Merged
rdheekonda merged 2 commits into
mainfrom
fix/eng-7284-airt-model-routing
Jul 1, 2026
Merged

fix(ai-red-teaming): route dn/* through proxy, keep local keys (ENG-7284)#66
rdheekonda merged 2 commits into
mainfrom
fix/eng-7284-airt-model-routing

Conversation

@rdheekonda

Copy link
Copy Markdown
Contributor

Summary

Follow-up to the SDK fixes in dreadnode-tiger #1840 / #1845, for the agent-generated attack workflow (attack_runner.py) — the path the AI Red Teaming agent runs in the TUI and cloud sandbox.

Previously the workflow only proxied models when OPENAI_BASE_URL was set. But the platform (both the cloud sandbox and the local TUI/CLI runtime) injects the LiteLLM proxy as DREADNODE_LLM_BASE / DREADNODE_LLM_API_KEY, so dn/* models fell through to litellm unresolved and failed with LLM Provider NOT provided — with the error text then reused for downstream attack steps.

Fix

Resolve every model role — target, attacker, judge, and transform — through resolve_dn_model_to_generator:

  • dn/* → proxy-configured Generator via DREADNODE_LLM_* (works in sandbox and local runtime).
  • everything else (groq/, anthropic/, openai/, …) → left untouched so litellm uses the user's own local provider keys (GROQ_API_KEY, OPENAI_API_KEY, …).

Both modes now work side by side. Model-id strings are preserved for the platform UI labels; the resolved *_GEN values drive inference. Bumps ai-red-teaming 1.4.1 → 1.4.2.

Validation (end-to-end on dev, prompt attack, real trials)

target attacker judge trials best result
dn dn dn 2 1.0 all → proxy (live via TUI, keylogger goal)
dn groq groq 2 0.95 dn→proxy, groq→local GROQ_API_KEY
groq dn dn groq→local, dn→proxy
groq groq groq 1 0.9 all → local key (regression)

No LLM Provider NOT provided errors in any combination. just validate + pre-commit clean.

🤖 Generated with Claude Code

… (ENG-7284)

The generated attack workflow routed models through the LiteLLM proxy only when
OPENAI_BASE_URL was set — but the platform (cloud sandbox and local TUI/CLI
runtime) injects the proxy as DREADNODE_LLM_BASE / DREADNODE_LLM_API_KEY, so
dn/* target/attacker/judge/transform models fell through to litellm unresolved
and failed with "LLM Provider NOT provided".

Resolve each model (target, attacker, judge, transform) with
resolve_dn_model_to_generator: dn/* ids become proxy-configured generators via
DREADNODE_LLM_*, while every other id (groq/, anthropic/, openai/, ...) is left
untouched so litellm uses the user's own local provider API keys. The two modes
now work side by side. Model-id strings are preserved for the platform UI labels.

Verified end to end on dev across combinations (all-dn, dn+local mixes, all-local):
trials run and route correctly with no provider errors.

Bumps ai-red-teaming to 1.4.2.
…SDK build

The generated workflow imported resolve_dn_model_to_generator from
dreadnode.generators.proxy, but execute_workflow runs the workflow under the
installed CLI tool's interpreter, whose proxy module can predate that symbol —
producing "ImportError: cannot import name 'resolve_dn_model_to_generator'" and
0 trials.

Inline the dn/* -> LiteLLM-proxy resolution (using only get_generator +
GenerateParams, present in every SDK build) instead of importing it. Verified
live: execute_workflow now succeeds on first try for dn/* (proxy) and non-dn/
(local provider key) models with no ImportError and no routing errors.
@rdheekonda rdheekonda merged commit 9a3f89b into main Jul 1, 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