You do not know your agent's weaknesses until you attack it

Anthropic ran 1,700 hours of red-teaming against one defense and still measured a residual. Continuous adversarial testing is how you learn what gets through.

B

Balagei G Nagarajan

3 MIN READ


A red team continuously probing an agent while defenders patch the weaknesses it finds

Key facts.

  • Constitutional Classifiers were red-teamed across thousands of hours and attempts, reducing jailbreak success from 86% to 4.4% but not to zero (Anthropic, 2025).
  • Tool-poisoning benchmarks such as MCPTox systematize adversarial testing of real MCP servers (MCPTox, 2025).
  • Adversarial testing has to be continuous because new attack techniques and new tools change the surface constantly.
You attack continuously and patch; we watch for what the attacks miss.
— from "You do not know your agent's weaknesses until you attack it"

Why isn't a one-time security audit enough?

Because the attack surface moves. New injection techniques appear, new tools get added, models get swapped, and each change can reopen a hole the last audit closed. A point-in-time review certifies the agent as it was, not as it's. Continuous red teaming, automated adversarial suites running against every change plus periodic human red teams, keeps the picture current. The Constitutional Classifiers result is the proof: even an enormous, sustained effort leaves a residual, so the work is never finished, only kept up.

Cyclical diagram of attack, measure, patch, repeat as a continuous red-teaming loop

One-time audit vs. continuous red teaming

One-time auditContinuous red teaming
Certifies a snapshotTests every change
Misses new techniques and toolsCatches surface shifts as they happen
False sense of doneResidual measured and tracked

Constitutional Classifiers took thousands of red-team hours to reach 4.4%, not zero, and a stronger model won't end the incident: Crescendo still lands on GPT-4. (arXiv:2501.18837)

VibeModel's Pattern Intelligence Layer complements red teaming by detecting in production the attack patterns your tests are designed to surface, so a technique that slips past testing still shows up when it's used for real. You attack continuously and patch; we watch for what the attacks miss. Red teaming tells you the residual exists; we make sure the residual can't do harm unseen.

Frequently asked questions

How often should I red team?
Continuously for automated suites, on every meaningful change, plus periodic human red teams. The surface moves too fast for an annual review.

If even Anthropic leaves a residual, what's the point?
The point is to know the residual and contain it. You can't defend what you haven't measured, and red teaming is how you measure.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.