fix: Register DynamoAI guardrail initializer and enum entry

[Harshit28j]

Summary

Fixes #22773 — DynamoAI guardrail now properly registers with the initialization system, resolving the "Unsupported guardrail: dynamoai" error.

Changes

1. Added DYNAMOAI = "dynamoai" to SupportedGuardrailIntegrations enum
2. Implemented initialize_guardrail() function in dynamoai/__init__.py
3. Added guardrail_initializer_registry and guardrail_class_registry for proper registration

The DynamoAI guardrail was added in PR #15920 but was never wired into the registration system. The dynamic discovery mechanism at module load time looks for guardrail_initializer_registry in each guardrail hook's __init__.py — DynamoAI was missing this, causing lookups to fail.

🐛 Bug Fix

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 16, 2026 3:03pm

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing Harshit28j:litellm_fix_guardrails_dynamo (ed213ba) with main (3dccdde)}

[greptile-apps]

Greptile Summary

This PR fixes a long-standing gap where the DynamoAI guardrail (added in PR #15920) was never wired into LiteLLM's dynamic guardrail registration system, causing an "Unsupported guardrail: dynamoai" error at runtime. The fix follows the exact pattern established by all other hook-based guardrails (e.g. pangea, lasso, aim).

Changes:

• litellm/types/guardrails.py: Adds DYNAMOAI = "dynamoai" to SupportedGuardrailIntegrations enum in correct alphabetical order.
• litellm/proxy/guardrails/guardrail_hooks/dynamoai/__init__.py: Adds initialize_guardrail(), guardrail_initializer_registry, and guardrail_class_registry — the three artifacts that get_guardrail_initializer_from_hooks() / get_guardrail_class_from_hooks() in guardrail_registry.py scan for at import time.
• tests/test_litellm/proxy/guardrails/guardrail_hooks/test_dynamoai.py: New test file with mock-only tests covering enum presence, local and global registry discovery, and instance creation. No real network calls are made.

Notes:

• The implementation is clean and correct — previous issues raised in earlier review threads (syntax error, redundant self-import) have been resolved in this version.
• Two unused imports (os, pytest) remain in the test file — a minor style nit.

Confidence Score: 5/5

• This PR is safe to merge — it is an additive, non-breaking fix with no changes to existing behaviour.
• The change is minimal and surgical: one new enum value, one new __init__.py pattern that mirrors every other hook-based guardrail, and a new mock-only test file. There is no modification to existing logic, no risk of regression to other guardrails, and the dynamic discovery mechanism already handles the new entry automatically at module load. The only finding is two unused imports in the test file, which do not affect correctness.
• No files require special attention.

Important Files Changed

Filename	Overview
litellm/proxy/guardrails/guardrail_hooks/dynamoai/init.py	Correctly wires DynamoAI into the guardrail registration system by adding initialize_guardrail, guardrail_initializer_registry, and guardrail_class_registry — mirrors the established pattern seen in pangea, lasso, etc. Previous thread issues (syntax error, redundant import) are resolved in this version.
litellm/types/guardrails.py	Adds DYNAMOAI = "dynamoai" to SupportedGuardrailIntegrations enum in correct alphabetical position between BEDROCK and GUARDRAILS_AI.
tests/test_litellm/proxy/guardrails/guardrail_hooks/test_dynamoai.py	New mock-only test file covers enum presence, local registry contents, global registry discovery, and instance creation — all tests correctly mock litellm.logging_callback_manager.add_litellm_callback and make no real network calls. Two unused imports (os, pytest) are present.

Sequence Diagram

sequenceDiagram
    participant GR as guardrail_registry.py (import time)
    participant DISC as get_guardrail_initializer_from_hooks()
    participant INIT as dynamoai/__init__.py
    participant CB as litellm.logging_callback_manager

    GR->>DISC: scan guardrail_hooks/ directory
    DISC->>INIT: importlib.import_module("...dynamoai")
    INIT-->>DISC: exposes guardrail_initializer_registry {"dynamoai": initialize_guardrail}
    DISC-->>GR: discovered_initializers updated with "dynamoai"
    GR->>GR: guardrail_initializer_registry.update(discovered)

    Note over GR: At request time — guardrail config with guardrail: dynamoai

    GR->>INIT: initializer = guardrail_initializer_registry["dynamoai"]
    GR->>INIT: initialize_guardrail(litellm_params, guardrail)
    INIT->>INIT: DynamoAIGuardrails(api_key, api_base, ...)
    INIT->>CB: add_litellm_callback(_dynamoai_callback)
    INIT-->>GR: returns DynamoAIGuardrails instance

Loading

_{Last reviewed commit: ed213ba}

[greptile-apps]

No test covering the new registration

The PR fixes the "Unsupported guardrail: dynamoai" error by wiring the guardrail_initializer_registry and guardrail_class_registry, but there is no new test asserting that "dynamoai" is present in either registry. The existing test_guardrail_registry.py asserts presence of "aim", "aporia", "noma", etc., but does not cover "dynamoai".

Adding a focused assertion (similar to test_guardrail_class_registry) would serve as direct evidence that the bug is resolved:

def test_dynamoai_registry_resolution():
    from litellm.proxy.guardrails.guardrail_registry import (
        guardrail_class_registry,
        guardrail_initializer_registry,
    )
    from litellm.proxy.guardrails.guardrail_hooks.dynamoai.dynamoai import DynamoAIGuardrails

    assert guardrail_class_registry["dynamoai"] is DynamoAIGuardrails
    assert "dynamoai" in guardrail_initializer_registry

This mirrors what already exists for noma and noma_v2 in test_noma_registry_resolution.

Rule Used: What: Ensure that any PR claiming to fix an issue ... (source)

[Harshit28j]

@greptileai review