What a garak implementation plan has to decide before the first scan
A team that needs repeatable LLM security testing and is weighing a garak program should know one thing first: garak is licensed under Apache 2.0, so the license fee is zero and the cost sits elsewhere. It comes from model API or GPU time, from the engineering effort to configure targets and review results, and from the ongoing work of running scans on a schedule. The planning question is therefore not whether to buy a tool but which of these cost lines to size, who pays for each, and how often they recur. The plan starts with the triggers that justify a scanning program. The common ones are a new LLM application going into production, an audit or customer request asking for evidence of prompt injection or jailbreak testing, and a change of model, model version, system prompt or retrieval setup. Each trigger implies a different scope. A new application needs a full baseline run against the target as deployed. A model change needs a comparable rerun of the same probes so the results can be read side by side. Write down which triggers will start a scan, who initiates it, and how long results must be kept. Next, decide what garak will actually reach. garak can test Hugging Face Hub models, Replicate text models, OpenAI API models, AWS Bedrock foundation models, models reached through LiteLLM, gguf models through llama.cpp, and almost anything reachable over REST. For a custom application, the REST generator needs a YAML description of the endpoint, authentication headers and response parsing. Confirm early whether the target is a raw model or an application with a system prompt, filters and tools, because the second requires more configuration effort and changes what a failure means. Finally, settle who does the work. The choice between an in-house team and an implementation partner depends on skills and staffing, not on licensing, since the tool costs the same either way. An in-house team needs people who can write endpoint configuration, interpret probe failures and keep Python 3.11 environments current. A partner is useful when those skills are scarce or when the program must be delivered on a fixed scope. Either way, ask any quote to separate one-time setup from recurring scan operations and to state which model API or GPU charges are billed to the client and which are included.
What the garak implementation includes and what you receive
The implementation is a fixed-scope engagement, agreed in writing before work starts. Each work item below produces a named deliverable, and together they give your team a configured, documented and handed-over garak scanning program that you can run without us.
Scoping target models and applications
We list the models, endpoints and LLM applications that garak will test, and record the owner, hosting location and access path for each one. This step decides how many generator configurations you need and which probes are relevant. Check that the scope names every model version you intend to compare, because a change in model version changes the results. The output is a written target inventory that becomes part of the agreed scope.
Installing garak on a supported Python
We install garak from PyPI into a controlled environment running Python 3.11 or newer, which the PyPI package requires. We pin the garak version so that results stay comparable between runs. Confirm which operating system your scan hosts run, since the project is developed on Linux and macOS. The deliverable is a reproducible install with a documented version pin and environment setup steps.
Configuring generators for each target
We configure a generator for each target, such as Hugging Face Hub, OpenAI API, AWS Bedrock, LiteLLM, llama.cpp or a REST endpoint described in YAML. Each generator needs its own credentials, endpoint settings and rate limits. Confirm with your model provider which quotas and billing limits apply to scan traffic, since these set how fast a scan can run. The deliverable is a set of generator configuration files, with secrets referenced rather than stored in the files.
Selecting probes and detectors
We select the probes that match your risk areas, such as prompt injection, data leakage, jailbreaks or hallucination, and confirm the detectors that judge each probe's output. The default probewise harness runs each probe with its recommended detectors, and we document where that default is kept or changed. Each probe choice affects run time and API cost, so the selection is reviewed against your budget. The deliverable is a documented probe set with the reason for each inclusion.
Setting run profiles
We define run profiles that set generation counts, probe groups and target sets for different purposes, such as a quick pre-release check and a full periodic assessment. garak makes 10 generations per prompt by default, and that setting multiplies cost, so each profile states its value explicitly. Agree which profile is used for baselines before the first run. The deliverable is a profile file for each purpose, with run commands that reference it.
Writing the scan runbook and handling reports
We write the runbook that covers how scans are started, where JSONL reports and the garak.log file are stored, who reviews failures, and how a probe marked FAIL is triaged. The JSONL report records every attempt and its evaluation, so retention and access rules for it must be set with your security team. We also provide run scripts that write reports to a fixed location. The deliverables are the runbook, the run scripts and a review procedure with named roles.
Handing over to your team
We walk your engineers through the configurations, profiles and runbook, and run a supervised scan with them so they can repeat it alone. We document open items and the decisions behind the configuration. Ask at quoting time what handover sessions are included and what is left for your team to finish after the engagement closes. The deliverable is a handover pack with the configuration files, documentation and a record of the supervised run.
What drives garak scan cost and duration
This table lists the factors that change how much a garak scanning program costs and how long each run takes, with a way to keep each one under control. Read it as a checklist for scoping: the first rows usually have the largest effect on recurring spend. Garak itself is free, so the totals come from model calls, compute, and the people who configure targets and review findings.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of target models and applications | Each model or application is a separate scan target with its own endpoint, credentials, and API bill. Costs grow with every target added to scope. | Start with the models and applications that face users or hold sensitive data. Add others only after the first baseline is agreed. |
| Number of probes and categories in scope | Garak probes cover hallucination, data leakage, prompt injection, toxicity, jailbreaks, and more. Each probe sends prompts to the target, so broader probe selection means more model calls per run. | Map probe categories to the risks in your threat model. Document which probes are excluded and why, so reviewers can see the decision. |
| Generations per prompt | Garak defaults to 10 generations per prompt. Each generation is a separate model call, so this setting multiplies API charges and runtime for every probe. | Confirm the setting with the partner before the first run. Lower values reduce calls, but results may not be comparable with earlier baselines, so change it once and record the change. |
| REST endpoint complexity | Authentication flows, custom headers, session handling, and non-trivial response parsing add configuration and debugging time. Slow or rate-limited endpoints lengthen every run. | Test the endpoint YAML with a small probe set first. Ask for the authentication method and response format in writing before scoping. |
| Number of environments | Running the same scans in development, staging, and production-like environments repeats model calls and compute in each one. Production-like targets may also need change approval and load limits. | Scan the environment that represents the release decision. Use the cheaper environments for tuning configuration, then run full scans where the results matter. |
| Compliance evidence requirements | If an assessor expects specific reports, retention periods, or traceable run records, more time goes into producing, labeling, and storing JSONL reports and logs. Evidence work recurs with each assessment cycle. | Agree the evidence list before scanning starts. Confirm with your assessor what they will accept, then build the report template once. |
| Number of reviewers who must read results | Each failed probe must be triaged, and garak reports can be large. More reviewers, or a formal sign-off chain, adds staff time to every run. | Summarize results by category and severity. Limit full-detail review to flagged probes and agree a sign-off owner for each system. |
| Recurring model API and GPU charges | API charges and GPU time recur with every run. They scale with generations per prompt and probe count, and they repeat each time a model or prompt template changes. | Request a per-run estimate from the partner based on your own API pricing, GPU rates, and endpoints. Ask which runs are scheduled and which are on demand. |
How a garak scanning program moves from scoping to routine runs
This sequence turns garak from a tool someone runs once into a repeatable program: each phase produces a defined artifact, from a target inventory and a verified generator configuration through to a baseline, triaged findings, tracked fixes and a scheduled run cadence. Durations depend on the written scope, so ask for a schedule tied to it.
Scope the targets and build the inventory
The team lists the models and applications in scope, including hosted model APIs, self-hosted models and any custom LLM application or gateway. For each target, the owner, the access method, the data it touches and whether it is production or a non-production copy are recorded. Output: a signed target inventory and a written scope that states which probe families are in and which are excluded. Ask DeployOpen to tie the delivery schedule to this written scope before work starts.
Set up the environment and dependencies
DeployOpen installs garak from PyPI into an isolated Python environment, using Python 3.11 or newer as the PyPI package requires, on a scan host inside your infrastructure. Dependencies for the chosen generators are installed, and the API keys are stored in your secrets manager rather than in config files. Output: a documented environment with a pinned garak version and a recorded install log. Confirm with your security team where the scan host sits and who can read its output directory.
Configure generators and run a smoke test
Each target is wired to a garak generator: the built-in options for Hugging Face Hub, OpenAI API, AWS Bedrock, LiteLLM, llama.cpp or Replicate models, or the REST generator with a YAML file describing your endpoint, headers and response parsing. A single low-volume probe is run to confirm that requests reach the target, responses parse correctly and the JSONL report is written. Output: a passing smoke test for each target and a saved configuration file under version control.
Run the baseline scan with the probewise harness
The first full scan uses the default probewise harness, which runs each selected probe with its recommended detectors. Garak makes 10 generations per prompt by default, so the number of attempts and the request volume against each target should be estimated before the run, using the model API pricing or GPU time you will pay for. Output: a baseline JSONL report and garak.log for each target, stored with the run settings. This baseline is the reference every later run is compared against.
Triage results and review detectors
Reviewers read the FAIL entries in the JSONL report, where a probe is marked FAIL with a failure rate when any attempt produces undesirable output. They sample the flagged attempts to separate true weaknesses from detector false positives, and record whether a detector needs tuning or replacing. Output: a triage log that classifies each FAIL as confirmed, false positive or needs investigation, with the reviewer's name and date. Detector changes are versioned so later runs remain comparable.
Track remediation from failures to retests
Each confirmed FAIL becomes a ticket that names the target, the probe, the failure rate from the JSONL report and an example attempt with sensitive content removed. The owning team changes the prompt handling, guardrails, model configuration or application logic, and the ticket moves to a retest. Repeat runs with the same probes and settings confirm whether the failure rate has dropped. The application owner signs off the fix, and the security lead signs off closure of accepted risks. Output: a closed ticket set with before and after reports attached.
Hand over and schedule routine runs
DeployOpen hands over the scan runbook, configuration files, pinned garak version, triage procedure, ticket workflow and the list of named owners. The agreed cadence is set in writing, along with the trigger for an extra run after a model, prompt or application change. Your team confirms it can run a scan, read the report and raise a ticket without outside help. Output: a handover record with a scheduled run calendar, and a decision on whether ongoing support or a retainer covers upgrades and new probes.
Which models, applications and probes to put in the first scan
The first decision is what garak should test. It can probe a model directly through a supported generator, such as Hugging Face Hub models, Replicate text models, OpenAI API models, AWS Bedrock foundation models, models reached through LiteLLM, or gguf models run through llama.cpp. A direct model scan answers a narrow question: how does this base model behave when prompted without the rest of the product around it. That is useful for model selection, but it does not show what your users can reach. For most organizations the more relevant target is the application itself, meaning the system prompt, retrieval layer, guardrails, tool access and output handling that sit between a user and the model.
To test a custom application, garak's REST generator connects to any endpoint that returns plaintext or JSON, configured through a short YAML file that describes the request and response shape. This is the case where the application's own prompt handling and tools matter. A prompt injection that a bare model ignores may succeed when the application concatenates untrusted content into its prompt, or when a tool call can be steered into an action. Before scanning, confirm with the application owner which tools the endpoint can invoke, whether it uses retrieval, and whether a test session can be isolated from production data. Those answers determine which probes are meaningful and which results need a human review.
garak groups its probes by weakness. The main families cover hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks, along with other weaknesses. A first scan usually narrows this set to the risks the application can actually produce. A internal summarization tool with no tools and no external content has a very different exposure from a customer-facing agent that reads email. Running every family against every target produces long reports that are hard to act on, and it multiplies API or GPU time without adding decisions. Write down the risks for each target, map them to probe families, and record why any family was left out so the omission can be revisited.
The garak README describes three categories of probe. Static probes send fixed prompts that were written in advance. Dynamic probes adjust the prompt based on the model's responses. Adaptive probes go further and change their approach across attempts to find inputs that work. In plain terms, static probes are cheap and repeatable, dynamic probes explore variations, and adaptive probes spend more requests searching for a weakness. The first scan should favor the categories that give repeatable baselines, because a later comparison is only meaningful if the same probes ran against the same target. Confirm the current probe list and the categories for your installed version with the garak user guide at docs.garak.ai, since the probe set changes between releases.
A probe does not decide pass or fail on its own. Each probe has recommended detectors that inspect every generation for undesirable output, and an evaluator turns those detector results into a verdict. By default garak makes 10 generations per prompt, and it marks a probe as FAIL with a failure rate when any attempt produces undesirable output. That means one bad generation out of ten can fail the probe, so a FAIL needs human review of the JSONL report before anyone treats it as a confirmed weakness. Before the first run, confirm with the maintainers' documentation at docs.garak.ai which detectors apply to your use case, and decide who reviews the flagged attempts and how false positives are recorded.
Which parts of a garak program your team keeps and which a partner can take
This table compares each part of a garak scanning program against who usually carries it and the skills it requires, so you can see where your team already has the capability and where outside help shortens the learning curve. Read the in-house column as the default for most teams with Python and security testing experience, and treat the outsourced column as the work a partner can take on while your staff learn the platform. The main takeaway is that triage and remediation depend on your application knowledge, while endpoint setup and first pipeline builds depend on hands-on garak experience.
| Work part | Usually in-house or outsourced | Skills needed |
|---|---|---|
| Business risk ownership | In-house | Authority to accept or reject risk for each application, and knowledge of which harms matter to its users and regulators |
| Target inventory | Either, usually in-house with partner input | Knowledge of every model, gateway and LLM application in use, including versions, owners and data they touch |
| Generator and REST endpoint configuration | Often outsourced at first | Experience writing garak YAML for REST generators, handling authentication headers and parsing JSON or plaintext responses |
| Probe and detector selection | Either, depending on team experience | Understanding of garak probe families, their recommended detectors and how each maps to the threats your application faces |
| Run automation | Often outsourced at first, then in-house | Python packaging, scheduling, secrets handling for API keys and retention of JSONL reports and garak.log files |
| Result triage | In-house | Reading JSONL attempt records, separating true failures from detector noise and judging exploitability in your application context |
| Remediation of application findings | In-house | Application design, prompt and guardrail engineering, output filtering and access control changes in your own codebase |
| Executive reporting | In-house, with partner drafting support possible | Translating failure rates and affected probes into business impact, owner accountability and trend statements for leadership |
What usually goes wrong in a garak scan program and how to prevent it
Most garak programs fail through operational habits rather than through the tool itself. The cards below cover the failure modes we see most often when teams plan a scanning program, each paired with a prevention step to build into the plan before the first run.
Scans hit production endpoints
Teams often point garak at a live customer-facing endpoint to save time on setup. Each probe sends many prompts, and by default garak makes 10 generations per prompt, so a single run can add meaningful load and per-token cost to a production model. Prevention: scope each run against a non-production or dedicated test deployment, set a rate and budget ceiling in the plan, and confirm with the model owner which endpoint and API key each run uses before it starts.
API keys left in configs and logs
Generator configuration files for OpenAI, Bedrock or a REST gateway usually contain credentials, and those files get copied into repositories and tickets. Keys can also surface in debugging output. Prevention: load secrets from a managed secret store or environment variables at run time, keep generator YAML free of literal credentials, and review garak.log and run configurations for leaked values before sharing them.
Comparing results across versions
garak is released frequently, and probes, detectors and their prompts can change between versions. A failure rate from one release may not be comparable with a rate from another, so a trend line can show change that comes from the tool rather than the model. Prevention: pin the garak version in your environment, record it with every JSONL report, and re-run the baseline before adopting a new release.
Probe sets changed without a baseline
Adding or removing probes between runs makes it impossible to say whether a model improved, regressed or was simply tested differently. This often happens when an engineer adds a probe family for one investigation and never reverts it. Prevention: define a named probe set for each scan type, store it in version control, and record a baseline run that all later runs are compared against.
Reports exposing harmful content
JSONL reports record every attempt and its evaluation, and garak.log accumulates across runs. Together they can contain jailbreak text and generated toxic or sensitive output, which may be unsuitable for wide access. Prevention: store reports in a restricted location with access limited to named reviewers, set a retention period agreed with the security and legal teams, and avoid pasting raw attempts into tickets or chat channels.
Findings with no owner
A scan that produces failing probes but no named owner usually stalls in a shared inbox. Teams then cannot show remediation or acceptance of the residual risk. Prevention: assign each failing probe family to an accountable owner, route findings into the defect tracker used for the application, and define who can accept a risk and how long that acceptance lasts.
Treating a clean run as proof
A run with no FAIL results only shows that the probes selected, under the configured generator and detectors, did not trigger the tested behavior. It says nothing about untested attack types, other prompts or future model updates. Prevention: word reports as evidence of tested behaviors, list the probes and coverage limits alongside every result, and keep manual red teaming and monitoring in the plan for the gaps garak does not cover.
What a garak program costs to run after go-live
This table lists each recurring cost of a garak scanning program after go-live, what sets its size, and who usually pays for it. garak itself is free under the Apache 2.0 license according to its maintainers, so the recurring spend sits in model access, compute, hosting and people. Ask your partner for a per-run cost model, and measure your own API spend during the baseline phase before you set a budget.
| Recurring cost | What sets it | Who pays |
|---|---|---|
| Model API charges per run | Number of probes selected, generations per prompt (10 by default), number of target models, and how often scans repeat | Your organization, billed by the model provider |
| GPU or compute time for local models | Size of the model (for example gguf models run through llama.cpp or Hugging Face models), hardware type, and total scan duration | Your organization, through cloud or data center billing |
| Scan host hosting | Where the scan host runs, whether it is always on or started for scheduled runs, and the logging and report storage it needs | Your organization, through your infrastructure budget |
| Engineering time for scheduled runs and endpoint changes | Number of scheduled pipelines, how often target endpoints or authentication change, and how much the REST generator configuration is maintained | Your team, or the partner under a retainer if agreed in writing |
| Triage and remediation time | Volume of FAIL results per run, false positive rate after detector review, and the number of owners who must act on findings | Your security, product and AI engineering teams |
| Upgrade effort when garak releases change | Frequency of releases, how far you lag the current version, and changes to probes or report formats that affect your baseline comparisons | Your team, or the partner under a support agreement |
| Storage and review of JSONL reports and garak.log | Retention period, number of runs, and how long reports must be kept for internal or assessor review | Your organization, through storage and records policy |
What your team needs to provide before a garak scan can start
The inputs your team provides will set the schedule for a garak program more than the tool itself. garak is free and Apache 2.0 licensed, so most delays come from waiting for access, decisions and reviewers rather than from installing or running the scanner. Before any scope is agreed, confirm that the items below are in place or have an owner and a date. An implementation partner will expect them in writing, and a quote will usually assume they are available when work begins.
Start with people. Each target application needs a named owner who can answer questions about its purpose, users, data and intended behavior. garak results are only useful when someone can say what a finding means for that product. Next, you need a decision on which risks matter for each application, such as prompt injection, data leakage, toxicity, hallucination or jailbreaks. This decision decides which probes and detectors belong in scope. Without it, the team will either run far more probes than it can review or miss the weaknesses that matter most to the business.
Access comes next, and it is where most delays occur. For each model provider, supply an API key or service account with a spending limit set by your finance or platform team. Model-based scans consume paid API calls or GPU time, and each run's cost depends on the probes selected and the number of generations requested. For custom applications, provide REST endpoint access in a non-production or agreed environment. Confirm with the application owner that load from scans is acceptable and that the endpoint behaves like the production version. Ask who holds the authentication material for that endpoint and how it will be issued to the scan host.
Prepare the scan host and storage. garak is installed from PyPI and the package requires Python 3.11 or newer, with development done on Linux and macOS. Provide a Linux or macOS host with that Python version, outbound network rules that reach the agreed endpoints and providers, and a place to store JSONL reports and the garak.log file. Reports contain every attempt and its evaluation, so storage should have restricted access and a retention rule that your data handling policy allows. Agree on who may read reports before the first run, because raw outputs can include harmful or sensitive text.
Finally, name a reviewer with authority to approve remediation priorities. garak marks a probe as FAIL when any attempt produces undesirable output, so a single run can produce many findings of varying severity. Someone must triage them, decide what is a true weakness in your context, and assign fixes to the application owner. Confirm how this reviewer will be available during scan cycles and who backs them up. Ask your partner to show how the scoped deliverables depend on each of these inputs, so that a late input moves the schedule in a visible and agreed way.
How much effort does a garak implementation take and what does it need from us
Does garak cost money to license?
No. garak is licensed under the Apache 2.0 license, and its maintainers describe it as a free tool. Licensing adds no cost, but a scanning program still spends money in other places. Each run sends prompts to the model under test, so API charges or GPU time recur with every scan. Your engineers also spend time configuring targets, reviewing JSONL reports and triaging findings. Ask any partner to separate one-time setup from recurring run costs, and to state which model usage is billed to you directly. If you plan to redistribute garak inside your own product, have your legal team read the license text in the project repository before you start.
What drives the effort and cost of a garak implementation?
The number and type of targets matter most. Each model, endpoint or application adds configuration, authentication and review work. Access to the target drives time: a documented REST endpoint is simpler to connect than one behind single sign-on or a gateway that needs custom headers. Probe selection changes run length and API spend, because broader probe sets send more prompts. Reporting needs add effort when results must map to an internal risk register. Remediation ownership decides how quickly findings reach developers. Ask each quote to state its assumptions about these five items so you can compare them on the same basis.
How long does a first garak scan program take to set up?
No fixed duration can be given without a written scope. The schedule depends on how many targets are in scope, how quickly access and test accounts are provided, and how many probe families you want covered in the first pass. A sound quote should include a schedule with milestones such as target inventory, endpoint configuration, baseline run, findings review and handover. Ask for the milestone dates, the client dependencies behind each one, and what happens if access is delayed. Treat any single number offered before scoping as an estimate until the written scope confirms the targets.
What does the work need from our team before it starts?
Your team provides the inventory, access and the decisions that belong to your organization. Typical inputs include a list of models or applications to test, endpoint documentation, test credentials with limited permissions, a non-production environment where possible, network paths from the scan hosts, and a named owner who can accept findings. Someone must also decide who can view JSONL reports, since they can contain harmful generated content. Confirm storage and retention rules with your security team before the first run. Missing inputs can delay the schedule, so list each one as a client dependency in the written scope.
Can our internal team run garak on its own?
Yes, a team with Python and security testing experience can install garak from PyPI and run it. The package requires Python 3.11 or newer and is developed on Linux and macOS. The harder work is judgment: choosing probes that fit each application, writing endpoint configuration, interpreting FAIL results against your own policy, and keeping results comparable across releases. Teams with few spare engineers often find the review and remediation loop takes longer than the first run. Compare your internal estimate with a partner's written scope, including the time needed for ongoing operations.
How do we compare garak implementation quotes from partners?
Start by checking that each quote lists the same targets, probe families, deliverables and milestones. Look for separate lines for setup, run support, reporting, handover and any retainer. Confirm who pays for model API or GPU costs, and whether the quote assumes access to production or only to staging. Ask how changes to scope are priced and approved. DeployOpen delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. It does not publish a price list, so a quote follows from the written scope.
Can garak scans run against our production systems?
Production scans are possible only with explicit approval from the system owner, and most first passes should use staging. Generative tests send many prompts. Each one consumes model capacity, may hit rate limits or incur charges, and may reach logs or downstream systems. Agree on request rates, time windows, a stop condition and a named contact before the run. Confirm whether the endpoint has safeguards that could block or distort the scan. Keep scan hosts isolated, protect API keys, and decide how generated output is stored and who can read it.
Which garak costs keep recurring after the first scan program?
The recurring costs are model API or GPU time for each scheduled run, engineering time to review results and triage findings, and upkeep of endpoint configuration when applications change. Updates also recur. garak v0.17.1 was released on 16 October 2026, so teams should expect new releases to arrive over time and should plan how they will test and adopt them. Pin the version you use so results stay comparable between runs. Ask any partner to show which of these costs are included in the quote, which are billed to you, and which need a separate agreement such as a retainer.
How DeployOpen scopes, delivers and hands over a garak program
DeployOpen approaches garak implementation planning as a written, fixed-scope engagement covering which models and applications are targeted, which probes run, and how results reach remediation. The work runs inside your own infrastructure and ends with documented runbooks your team can operate.
How we scope
- Inventory the models, gateways and applications in scope, including which generator type each one needs.
- Agree probe families and detectors against the risks your team cares about, such as prompt injection and data leakage.
- Record compute, model API usage and reviewer time as line items in the written scope before work starts.
How we build
- Install garak from PyPI on Python 3.11 or newer in a host you control, and pin the version used for baseline runs.
- Configure generators for each target, including a YAML description for any REST endpoint and its authentication headers.
- Run a baseline scan, confirm the JSONL reports and garak.log output, and document expected failure rates per probe.
How we hand over
- Deliver scan configurations, run scripts and a schedule so your team can repeat scans on the same settings.
- Document how to read the JSONL report, how FAIL results map to findings, and how to route them to owners for remediation.
- Walk your engineers through the runbook and record open questions for follow-up in the handover pack.
How we support
- Ongoing support, version upgrades and recurring scan operations are available as a retainer, scoped separately from the build.
- Re-run baselines when garak or a target model changes, so results stay comparable across releases.
- Confirm with your team which support tier, response expectations and reporting cadence fit your environment before signing.
