Is 42Crunch good for Few-shot poisoning test?
What middleBrick covers
- Black-box API scanning without agents or code access
- Read-only methods: GET and HEAD plus text-only POST
- LLM security probes across Quick, Standard, and Deep tiers
- OpenAPI 3.0/3.1 and Swagger 2.0 parsing with $ref resolution
- Authenticated scanning with Bearer, API key, Basic, and Cookie
- Continuous monitoring with diff detection and email alerts
Few-shot poisoning and the scope of middleware scanning
Few-shot poisoning attacks against LLM pipelines work by injecting crafted examples into prompts, function calls, or tool-usage patterns to shift model behavior. These attacks target prompt handling logic, tool selection, and context construction rather than network perimeter controls. middleBrick is a black-box API security scanner focused on HTTP interface risks such as injection vectors, validation gaps, authentication bypass, data exposure, and SSRF. Because few-shot poisoning requires deep insight into prompt templates, tool schemas, and runtime orchestration, it is outside the scope of what middleBrick can evaluate.
What middleBrick detects that is relevant to LLM security
middleBrick includes an LLM / AI Security category with 18 adversarial probes organized in three scan tiers: Quick, Standard, and Deep. These probes cover system prompt extraction, instruction override, DAN and roleplay jailbreaks, data exfiltration attempts, cost exploitation, encoding bypasses (base64/ROT13), translation-embedded injection, few-shot style poisoning probes, markdown injection, multi-turn manipulation, indirect prompt injection, token smuggling, tool-abuse patterns, nested instruction injection, and PII extraction. The scanner exercises API endpoints to observe whether responses reveal system instructions or sensitive data, but it does not assess the semantic correctness of prompt design or runtime guardrails that stop malicious examples.
Limitations relevant to few-shot poisoning testing
Few-shot poisoning depends on the structure of example sets, the ordering of demonstrations, and the presence of defensive instructions such as input validation or output filtering. middleBrick does not inspect application source code, model weights, or runtime prompt assembly logic, so it cannot verify whether injected examples are correctly rejected or isolated. The scanner can surface indicators like exposed system prompts or missing input sanitization that may reduce the effectiveness of prompt-level defenses, yet it cannot replace a thorough red-team engagement focused on the specific prompt orchestration pipeline.
How findings map to compliance and security frameworks
Where relevant, middleBrick maps findings to OWASP API Top 10 (2023), and it supports audit evidence for SOC 2 Type II and PCI-DSS 4.0 by surfacing related control observations such as insufficient authentication, broken access control, input validation weaknesses, and data exposure. For regulations and frameworks outside this set, the tool aligns with security controls described in relevant standards and helps you prepare for audit activities, but it does not certify compliance or guarantee adherence to any specific regulatory regime.
Alternative approaches for comprehensive few-shot poisoning assessment
A focused assessment of few-shot poisoning should combine code review of prompt templates, runtime instrumentation to monitor example parsing, and adversarial testing that manipulates demonstration order, content, and metadata. Where API endpoint testing is needed, middleBrick can be part of a broader strategy that includes SAST or runtime application self-protection tools. For dedicated prompt-injection and jailbreak testing, consider specialized tools such as PromptFuzz, LLMAttack, or custom scripts that iterate over example-level perturbations while measuring behavioral drift.