What is the difference between pre-deployment and post-deployment red teaming for LLM applications?

Why This Matters for Security Teams

Pre-deployment and post-deployment red teaming serve different risk windows, and treating them as interchangeable leaves gaps in both assurance and response. Before launch, the goal is to pressure-test prompts, tool use, access boundaries, and failure handling while the blast radius is still contained. After launch, the focus shifts to drift, new jailbreaks, new integrations, and changes in user behaviour that did not exist during testing. For LLM applications, that distinction matters because the attack surface evolves as quickly as the model, the prompts, and the surrounding workflow. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 supports continuous evaluation rather than a single assurance event. Security teams often miss that a clean pre-launch result does not mean the deployed system is stable, especially once retrieval sources, plugins, or agent permissions change. In practice, many security teams encounter LLM abuse only after the application has already been exposed to real users and real data, rather than through intentional testing.

How It Works in Practice

Pre-deployment red teaming is usually a bounded exercise carried out in development or staging. It tests the system before business users depend on it, so teams can safely probe prompt injection, data leakage, unsafe tool invocation, policy bypass, and weak refusal behaviour. It also helps validate whether human review steps, logging, and escalation paths actually work when the model produces risky output. For higher-risk systems, this is where teams should check whether the application can be coaxed into revealing secrets, making unauthorized actions, or misclassifying harmful requests. Post-deployment red teaming is different in both purpose and tempo. It is an ongoing control, not a one-off event. The objective is to re-test after releases, new model versions, prompt changes, retrieval updates, or connector changes. It also covers threat patterns that only emerge once adversaries adapt to the live service. That means replaying new jailbreaks, testing for regressions, and watching for changes in model behaviour over time. A practical program usually includes:

• Pre-launch adversarial testing of prompts, tools, and data boundaries.
• Release-gated retesting after each meaningful change to prompts, models, or plugins.
• Post-launch monitoring for abuse patterns, anomalous outputs, and control failures.
• Clear severity criteria so findings lead to rollback, patching, or policy changes.

For threat modelling, teams often map findings to the MITRE ATLAS adversarial AI threat matrix and, where agent workflows are involved, the CSA MAESTRO agentic AI threat modeling framework. These controls tend to break down when deployments are highly dynamic, because prompt, retrieval, and tool changes happen faster than the retesting cycle.

Common Variations and Edge Cases

Tighter red teaming often increases delivery overhead, requiring organisations to balance confidence against release speed. That tradeoff becomes sharper in applications with rapid model iteration, multiple tool integrations, or strong business pressure to ship features quickly. There is no universal standard for how often post-deployment red teaming must occur, but current guidance suggests the cadence should reflect exposure, change rate, and impact. A common edge case is the model that appears stable in a sandbox but behaves differently once real documents, external tools, or production traffic are introduced. Another is the agentic workflow where pre-deployment tests focus on the base model but miss the orchestration layer, where abuse often happens. In those environments, red teaming should evaluate the full path from user input to model reasoning to tool execution, not just the prompt layer. For organisations seeking a structured profile for generative AI governance, the NIST AI 600-1 Generative AI Profile is useful, while OWASP Top 10 for Agentic Applications 2026 helps teams distinguish model risk from orchestration risk. Best practice is evolving, but one principle is consistent: post-deployment testing should be designed to detect change, not just confirm yesterday's findings.

Related resources from NHI Mgmt Group

• What is the difference between LLM red teaming and LLM vulnerability scanning?
• What is the difference between pre-deployment scanning and runtime protection?
• What is the difference between prompt testing and red-teaming agentic AI?
• What is the difference between red teaming an AI system and proving it is safe?