Notifications
Clear all
Topic starter
19/08/2026 3:36 pm
TL;DR: Most enterprise AI red teaming still tests a model once, against anticipated threats, before production, but ActiveFence argues that real incidents emerge later as systems drift, users adapt, and agents touch more of the stack than the lab can model. Continuous testing, runtime guardrails, and post-launch enforcement are now the governing controls, not optional extras.
NHIMG editorial — based on content published by ActiveFence: What AI Red Teaming Looks Like Outside the Lab
By the numbers:
- In February 2026, Cisco reported an average jailbreak success rate of 64% across models.
- Cisco found peak success rates for open-source models reached 93% during multi-turn attacks.
- A joint paper from researchers at OpenAI, Anthropic, and Google DeepMind found adaptive attacks succeeding more than 90% of the time against published model defenses.
Questions worth separating out
Q: How should security teams use continuous automated red teaming in practice?
A: Use it as a control verification loop, not as a substitute for human red teaming.
Q: Why do AI agents create a governance problem for IAM teams?
A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access.
Q: What breaks when AI controls stop at pre-deployment testing?
A: Pre-deployment testing cannot stop a compliant model from making risky decisions in a live workflow or through connected tools.
Practitioner guidance
- Build continuous AI testing into the production lifecycle Run adversarial checks before launch, at runtime, and after model or prompt changes so drift is tested as a standing condition, not a one-off review.
- Map every agent tool and credential path Document which APIs, systems, and service tokens an AI agent can reach, then apply least privilege and separate approval for higher-risk actions.
- Create enforcement controls that can fail closed Design guardrails so policy violations can block responses, disable tools, or restrict delegation before harmful actions propagate downstream.
What's in the full article
ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:
- Mo Sadek's live talk framing on why enterprise red teaming fails when it is not continuous
- The full pre-launch, runtime, and post-launch control model used to structure the argument
- The five practical directives on ownership, drift, and learning velocity in their original context
- The related AI red teaming resources and product-specific walkthroughs referenced at the end of the post
👉 Read ActiveFence's analysis of why AI red teaming must extend beyond the lab →
AI red teaming and runtime drift: what security teams miss?
Explore further
19/08/2026 4:16 pm
AI red teaming is becoming a lifecycle governance problem, not a one-time evaluation exercise. The article is right to distinguish tests from continuous security assurance. In AI programmes, the gap between pre-launch testing and production drift is where policy failures, unsafe outputs, and unauthorised tool use emerge. Practitioners should treat this as an operating model issue, not a point solution problem.
A question worth separating out:
Q: Who is accountable when an AI system makes a harmful decision?
A: Accountability should follow the identity chain that authorized, configured, or triggered the action, including the human owner, the platform team, and any delegated agent or tool account. If the organisation cannot name that chain, the governance model is too weak for regulated AI use.
👉 Read our full editorial: AI red teaming fails when testing stops at pre-launch
