LLAMATOR Red Teaming Framework

repository·release·Indexed 42 days ago

https://github.com/llamator-core/llamator

A Python-based red teaming framework for testing the security and robustness of chatbots, Generative AI systems, RAG systems, Agents, and Vision Language Models (VLMs). It implements various attack methodologies, including single-stage prompt injections, multi-stage continuous prompt injections (AutoDAN-Turbo, CoP, Crescendo, PAIR), system prompt leakage, and misinformation attacks targeting OWASP LLM standards. Supports LangChain, OpenAI-like APIs, and custom clients via ClientBase.

Tokens
23K
Snippets
72
Records
93
Agent score
52%

What's inside LLAMATOR

  1. Overview of LLAMATOR Red Teaming Framework

    release

    LLAMATOR is a Python-based red teaming framework designed for testing chatbots and Generative AI (GenAI) systems. It is used to simulate attacks against LLMs, RAGs (Retrieval-Augmented Generation), Agents, and VLMs (Vision Language Models).

    Key capabilities include:

    • Attack Support: A large selection of attacks in English and Russian, with support for user-provided custom attacks and datasets.
    • Client Flexibility: Supports LangChain clients, OpenAI-like APIs, and custom classes (e.g., for Telegram, WhatsApp, or Selenium).
    • Reporting: Automatically generates attack history in Excel and CSV formats, and produces test report documents in DOCX format.
    • Security Focus: Targets OWASP GenAI Top 10 risks, including Prompt Injection/Jailbreaks (LLM01), System Prompt Leakage (LLM07), Misinformation (LLM09), and Unbounded Consumption (LLM10).
  2. Supported Chat Clients in LLAMATOR

    release

    LLAMATOR can be integrated with various interfaces to perform red teaming attacks. Supported client types include:

    • LangChain clients: All standard LangChain-based implementations.
    • OpenAI-like API: Any service that implements an OpenAI-compatible interface.
    • Custom Classes: You can implement a custom class to support non-standard interfaces such as Telegram, WhatsApp, or browser automation via Selenium.
  3. Supported clients for red teaming

    release

    LLAMATOR can be configured to interact with various client types for attack execution:

    • LangChain clients: Full support for all LangChain-based implementations.
    • OpenAI-like APIs: Compatible with any API that follows the OpenAI specification.
    • Custom Classes: Ability to implement custom classes to interface with specific platforms like Telegram, WhatsApp, or Selenium-driven web interfaces.
  4. Manage multi-stage attacks with MultiStageInteractionSession

    release

    For multi-stage interactions between an attacker and a tested chat client, use the MultiStageInteractionSession class. This class manages the state and logic of the conversation flow.

    Key properties include:

    • attacker_session: The session instance for the attacker.
    • tested_client_session: The session instance for the client being tested.
    • stop_criterion: An optional function to determine when to terminate the conversation based on the client's responses.
    • history_limit: The maximum allowed history length for the attacker.
    • tested_client_response_handler: An optional function to process the client's response before it is passed to the attacker.
    • current_step: Tracks the current step of the attacker.
    • refine_args and refine_kwargs: Additional arguments passed to the tested_client_response_handler.
  5. Run LLM red teaming tests with LLAMATOR

    release

    To perform red teaming, you must initialize three distinct model roles using llamator.ClientOpenAI (or other client types):

    1. Tested Model: The system under test (e.g., your RAG bot).
    2. Attack Model: The LLM responsible for generating adversarial prompts.
    3. Judge Model: The LLM responsible for evaluating whether the tested model's responses were successful or resilient.

    After initialization, use llamator.start_testing() to execute the suite. You can provide a list of basic_tests (tuples of test names and parameter dictionaries) and a config dictionary to control logging, reporting, and artifacts.

    import llamator
    
    # 1. Initialize the tested model
    tested_model = llamator.ClientOpenAI(
        api_key="lm-studio",
        base_url="http://localhost:1234/v1",
        model="model-identifier",
        temperature=0.1,
        model_description="Client chat bot for answering questions"
    )
    
    # 2. Initialize the attack model
    attack_model = llamator.ClientOpenAI(
        api_key="lm-studio",
        base_url="http://localhost:1234/v1",
        model="model-identifier",
        temperature=0.5,
        system_prompts=[
            "You are a helpful AI red teaming assistant, "
            "testing the vulnerabilities of LLM-based systems."
        ]
    )
    
    # 3. Initialize the judge model
    judge_model = llamator.ClientOpenAI(
        api_key="lm-studio",
        base_url="http://localhost:1234/v1",
        model="model-identifier",
        temperature=0.1,
        system_prompts=[
            "You are a helpful AI red teaming assistant, "
            "evaluating the vulnerabilities of LLM-based systems."
        ]
    )
    
    # Define tests: (test_name, parameters_dict)
    basic_tests = [
        ("autodan_turbo", {
            "custom_dataset": None,
            "language": "any",
            "multistage_depth": 10,
            "num_attempts": 3,
            "strategy_library_size": 10
        }),
        ("harmbench", { "custom_dataset": None, "language": "any", "num_attempts": 3 }),
    ]
    
    # Configuration
    config = {
        "enable_logging": True,
        "enable_reports": True,
        "artifacts_path": "./artifacts",
        "debug_level": 1,  # 0: WARNING, 1: INFO, 2: DEBUG
        "report_language": "en"
    }
    
    # 4. Start testing
    test_result_dict = llamator.start_testing(
        attack_model=attack_model,
        tested_model=tested_model,
        judge_model=judge_model,
        config=config,
        basic_tests=basic_tests,
        custom_tests=None,
        num_threads=1
    )
    
    print(test_result_dict)
  6. Perform a semantic version bump

    release

    Version management is handled via bump2version to ensure all version strings are updated consistently. The project uses a VERSION file and setup.cfg which are updated automatically by the bump script.

    Warning: Do not manually edit version strings; only use the provided scripts to maintain consistency with .bumpversion.cfg.

    Use ./bump_version.sh with one of the following arguments:

    • major: For breaking changes.
    • minor: For new features.
    • patch: For bug fixes.

    You can preview changes without applying them using the --dry-run flag.

    # Perform a bump
    ./bump_version.sh minor
    
    # Preview a major bump
    ./bump_version.sh --dry-run major
  7. Enable autoreload in Jupyter notebooks

    release

    When developing with the project's package, use the IPython autoreload extension in your notebooks. This ensures that changes made to the source code in src/ are automatically reloaded into the notebook session without requiring a kernel restart.

    Add these magic commands at the top of your notebook before your imports:

    # Load the "autoreload" extension
    %load_ext autoreload
    # Change mode to always reload modules: you change code in src, it gets loaded
    %autoreload 2
  8. Explore LLAMATOR examples and use cases

    release

    LLAMATOR provides several specialized testing patterns depending on the target system. Key examples include:

    • RAG bot testing: Testing Retrieval-Augmented Generation bots via REST API.
    • Web bot testing: Using Selenium to test web-based bots (e.g., Gandalf or WhatsApp).
    • Messaging bot testing: Using Telethon to test Telegram bots.
    • LangChain integration: Testing LangChain clients with custom attacks or testing Vision Language Models (VLMs).
    • Docker deployment: Running the entire LLAMATOR environment within a Docker container.