A first red-team baseline for Granite on OpenShift AI with NVIDIA garak

Red Hat has published a hands-on learning path for running NVIDIA’s open source garak scanner against a Granite model in Red Hat OpenShift AI. The 50-minute path starts in the Developer Sandbox, creates a JupyterLab workbench, runs a prompt-injection probe and uses the output to decide whether the model needs additional guardrails.

The useful part is not that a scanner can produce a report. It is that Red Hat puts the scan inside the same platform workflow practitioners can repeat as models, prompts and application controls change.

What the path builds

The Red Hat Developer learning path uses Granite 3.1 8B as its target and divides the exercise into three stages: understanding AI red teaming, running a first garak scan, and interpreting the results to establish a baseline.

Setup happens in an OpenShift AI project on the free Developer Sandbox. The user creates a small JupyterLab workbench with a data-science image, then clones Red Hat’s dev-sandbox-garak repository. According to the guide, the workbench receives the authentication it needs through the OpenShift service account, removing a separate credential-configuration step from the exercise.

The resulting workflow is deliberately narrow. It runs a prompt-injection probe, examines the model’s failure rate and uses the report to identify where targeted guardrails may be needed. Red Hat also frames broader scans and CI/CD integration as possible next steps rather than claiming that one probe proves a model safe.

Why the baseline matters

A model red-team result is tied to a particular model, deployment and test configuration. Changing the model version, system prompt, retrieval layer or surrounding guardrails can change the result. The guide’s strongest operational idea is therefore the baseline: record an initial result, apply a control, then reassess against the same class of probes.

That makes the exercise useful to platform and application teams even though it is beginner material. The OpenShift AI workbench provides a repeatable place to run the scanner, while garak supplies probes and detailed results that can be reviewed with a security team.

What to try next

Teams evaluating the path should preserve the scanner configuration and result artifacts from the first run, then repeat the test after adding a guardrail or changing the deployed model. They can also expand beyond prompt injection before treating the exercise as a release gate.

The key boundary is explicit in Red Hat’s own progression: a first garak scan establishes evidence about one tested configuration. It does not certify the whole application. Used that way, the learning path is a practical starting point for making model testing repeatable on OpenShift AI rather than a one-off demonstration.