garak

Garak scans LLMs for vulnerabilities by routing prompts through a modular harness system that abstracts different model providers (OpenAI, Anthropic, Ollama, vLLM, etc.) behind a unified interface. Each harness handles authentication, rate limiting, and response parsing for its target model, allowing the same vulnerability test suite to run against any LLM without code changes. The architecture uses a plugin-based loader pattern to dynamically instantiate harnesses at runtime based on configuration.

Garak organizes vulnerability tests as 'probes' — modular test units that generate adversarial prompts, send them to a target LLM via a harness, and evaluate responses against detection criteria. Probes are organized into taxonomies (e.g., 'jailbreak', 'prompt-injection', 'hallucination') and can be composed into test suites. Each probe implements a generate() method that produces test prompts (often using templates or programmatic construction) and a detect() method that classifies model responses as vulnerable or safe based on heuristics, keyword matching, or semantic similarity.

Garak exposes both a command-line interface (CLI) and a Python API for executing vulnerability scans. The CLI uses argparse to parse configuration and invoke the orchestrator, making garak accessible to non-programmers. The Python API provides classes and functions for programmatic test execution, enabling integration into Python-based workflows, notebooks, and CI/CD pipelines. Both interfaces share the same underlying orchestrator, ensuring consistent behavior. The architecture uses a facade pattern to abstract CLI and API differences, allowing users to choose the interface that best fits their workflow.

Garak provides a configuration-driven orchestration layer that chains together harnesses, probes, and detectors into executable test suites. Users define test runs in YAML/JSON config files specifying which models to test, which probes to run, and how to aggregate results. The orchestrator handles sequential or parallel probe execution (depending on harness concurrency support), collects results, and generates structured reports (JSON, CSV, HTML) with vulnerability metrics, model comparisons, and risk summaries. The architecture uses a run manager pattern to track test state and enable resumable/incremental scanning.

Garak's probes generate adversarial prompts using multiple strategies: template-based (filling placeholders in predefined jailbreak/injection patterns), programmatic (constructing prompts via Python logic to vary parameters), and potentially LLM-based (using auxiliary models to generate novel attack prompts). Probes can combine strategies — e.g., a jailbreak probe might use templates for known attacks and programmatic generation for variations. The generation layer abstracts prompt construction, allowing probes to focus on detection logic and enabling reuse of generation strategies across multiple probes.

Garak's detection layer evaluates LLM responses against multiple criteria to classify them as vulnerable or safe. Detection strategies include keyword/regex matching (e.g., detecting refusal phrases or harmful content keywords), semantic similarity (comparing responses to known vulnerable outputs using embeddings), classifier-based detection (using auxiliary ML models to score response safety), and custom heuristics. Probes compose these strategies — e.g., a jailbreak probe might use keyword matching for obvious bypasses and semantic similarity for subtle ones. The detection layer is decoupled from prompt generation, allowing the same response to be evaluated by multiple detectors.

Garak organizes vulnerabilities into a hierarchical taxonomy (e.g., 'jailbreak', 'prompt-injection', 'hallucination', 'bias', 'privacy') with subtypes and specific probes for each category. The taxonomy is exposed as a discoverable API — users can list available probes, filter by vulnerability type, and understand the coverage of each category. The taxonomy structure enables organized reporting (grouping results by vulnerability class) and helps users understand which attack vectors are tested. The architecture uses a registry pattern to dynamically load probes and organize them by taxonomy.

Garak supports scanning multiple LLMs in a single test run, aggregating results across models to enable comparative analysis. The orchestrator manages harness instances for each model, routes probes to all harnesses, and collects results in a unified format. Aggregation includes per-model vulnerability counts, cross-model comparisons (e.g., 'Model A is vulnerable to X, Model B is not'), and overall risk rankings. The architecture uses a result collector pattern to normalize outputs from different harnesses and enable flexible aggregation strategies.

Garak provides a harness base class that developers can subclass to add support for new LLM providers or custom deployments. A harness implements methods for authentication, prompt submission, response retrieval, and error handling. The framework handles harness discovery and instantiation via a plugin loader, allowing new harnesses to be added without modifying core garak code. Harnesses can implement provider-specific optimizations (e.g., batch API calls, streaming responses, custom retry logic) while maintaining a uniform interface for the orchestrator. The architecture uses dependency injection to pass configuration to harnesses at runtime.

Garak provides a probe base class that developers can subclass to implement custom vulnerability tests. A probe implements generate() (to produce test prompts) and detect() (to evaluate responses) methods. The framework handles probe discovery, instantiation, and execution via a plugin loader. Custom probes can implement domain-specific attacks, novel detection strategies, or variations of existing probes. The architecture uses a probe registry to organize probes by taxonomy and enable dynamic filtering/selection. Probes can depend on external resources (templates, models, APIs) injected at runtime.

Garak can persist test results to local files (JSON, CSV) or external databases, enabling historical tracking of vulnerability trends across test runs. The result storage layer abstracts persistence details, allowing results to be written to multiple backends. Users can query historical results to track vulnerability remediation, model improvement, or regression detection. The architecture uses a result writer pattern to normalize outputs from different harnesses and enable flexible storage strategies. Results include metadata (timestamp, model version, probe version) to enable accurate historical comparison.