Defender Impact
CrowdStrike’s publication of the Request, Aggregate, Bypass (RAB) evasion methodology gives defenders the first named, structured framework for auditing where LLM safety classifiers fail — closing a gap in the defender’s threat model that has existed since organisations began relying on classifiers as a primary safety control. Without a shared vocabulary and documented technique set, security teams have had limited ability to systematically test, measure, or communicate the residual risk of classifier-protected LLM deployments.
Capability Overview
The CrowdStrike research describes a three-stage evasion pattern applicable against LLM safety classifiers. In the Request phase, an adversary issues benign-appearing queries that individually fall below classifier detection thresholds. In the Aggregate phase, outputs from multiple individually-passed queries are combined outside the classifier’s inspection scope — typically at the application layer or client side. In the Bypass phase, the aggregated output achieves the harmful result the classifier was designed to prevent, without any single interaction having triggered a detection event.
This methodology is significant because it exploits a structural assumption baked into most classifier architectures: that each inference call can be evaluated independently and that harmful content can be detected at the point of generation. The RAB pattern breaks that assumption by distributing the harmful signal across multiple, individually-innocuous interactions, reassembling it in a space the classifier cannot observe.
The research is framed for defenders — the explicit goal is to characterise a real attacker capability so that blue teams can model, test against, and architect controls that account for it. This positions the publication as a piece of collective-defense intelligence rather than an adversarial capability release.
Defensive Advances
- Named threat model: Defenders now have a concrete, citable technique (RAB) to anchor red-team scenarios, procurement discussions, and risk register entries around classifier limitations.
- Testable evasion scenarios: Security teams can design structured adversarial test cases that probe aggregation blind spots — something that previously required bespoke, undocumented research effort.
- Control gap identification: Organisations can use the RAB framework to audit whether their LLM deployment architecture gives any visibility into cross-session or cross-request aggregation, and prioritise remediation accordingly.
- Shared vocabulary for incident classification: When safety classifier failures occur in production, teams now have a documented technique to reference in post-incident analysis and reporting.
Residual Gaps
The research publication is a meaningful step, but realising its full defensive value requires organisational maturity that many teams have not yet reached. Key gaps include:
- AI red-team capability: Most organisations do not yet have the internal expertise to operationalise RAB-style test scenarios against their own LLM deployments. The research creates the playbook, but the players are still scarce.
- Cross-session visibility: Defending against aggregation-based evasion requires logging and correlating LLM interactions across sessions and users — a capability most current LLM observability tooling does not natively provide.
- Classifier coverage benchmarking: There is currently no standardised benchmark for measuring classifier coverage against RAB-style techniques, making it difficult to compare vendor claims or track improvement over time.
- Integration with SIEM/XDR pipelines: LLM interaction logs are rarely ingested into enterprise detection pipelines at a fidelity level that would support behavioural analysis across requests.
Framework Mapping
The RAB methodology maps directly to AML.T0015 (Evade AI Model) and AML.T0068 (LLM Prompt Obfuscation), with the aggregation phase representing a novel execution of AML.T0043 (Craft Adversarial Data) distributed across multiple inference calls. The structural reliance on classifier-only controls maps to OWASP LLM09 (Overreliance) — the risk that organisations treat model-layer safety controls as sufficient without complementary architectural safeguards.
Deployment Considerations
Organisations should treat this research as an input to their AI security testing programme immediately, even if full operationalisation takes time. Priority sequencing: (1) assess current classifier architecture for aggregation visibility; (2) review LLM observability logging for cross-session correlation capability; (3) incorporate RAB scenarios into the next scheduled AI red-team exercise. Organisations without an existing AI red-team function should consider this research a prompt to establish one.
Complementary controls include output filtering at the application layer (not just the model layer), rate and pattern analysis across user sessions, and human-in-the-loop review for high-sensitivity LLM workflows.
Defender Checklist
- Review LLM classifier architecture for single-request vs. cross-session inspection scope
- Add RAB-style scenarios to AI red-team test plan
- Assess LLM observability logging for cross-request correlation capability
- Update AI risk register to include classifier aggregation blind spots
- Evaluate whether LLM interaction logs are ingested into SIEM/XDR pipelines
- Brief application security teams on aggregation-layer risk outside classifier scope