When the audit tool itself is the attack

A system can return a valid-looking report without having performed the test it claims. That is not necessarily a hallucination. Sometimes the infrastructure around the model is built to deceive, or carries state it should not have retained.

Elastic's REF8801 investigation followed a fake Web3 accelerator advertising free AI credits and security audits. Its purported MCP audit service exposed 18 tool handlers that generated hard-coded or random-looking results rather than running the advertised checks. A fictitious project received a plausible numerical score. The surrounding campaign also shipped malicious launchers and a modified coding assistant that rewrote model-routing configuration and registered an attacker-controlled MCP server. A user could reasonably receive a report whose layout suggested inspection even though the checking operation never took place.

Two LiteLLM proxy bugs identify a different failure. A low-privilege user could change sensitive configuration through an authorization mistake; a separate nested routing input could send calls and the proxy's configured provider credentials to an unintended host. Those conditions require authenticated access, and the cited fixes matter. They still expose a design lesson: a gateway's apparent centralization does not assure data and secrets stay on intended routes unless it validates every effective routing parameter, not just top-level fields.

Chainguard's vLLM finding brings the risk into model serving. An allowed_token_ids mask could survive request-batch compaction and influence the next user's output. The response completed normally; the integrity error occurred in shared serving state. No malicious prompt was necessary in the victim's own request, and the report does not claim recovery of the victim's input.

These cases do not share one attacker or one vulnerability class. They share a failure of assumed provenance. An auditor needs a trace that real checks ran; a model gateway needs an independently enforced destination and credential boundary; a serving engine needs request-scoped state with no cross-client reuse. Signed-looking JSON, reassuring prose, or a successful HTTP status cannot substitute for evidence of the actual action. The decisive question is not whether the agent sounded confident, but which component executed the check or request and under whose authority.

A useful comparison distinguishes fabrication from isolation failure. In Apex Accelerator, the auditor itself did not perform its advertised measurement. In LiteLLM, the routing layer could send a genuine provider request through an unauthorized destination. In vLLM, the server could apply another client’s decoding restriction. A common test of output quality cannot validate all three: the first requires evidence that a check ran, the second destination and credential authorization, and the third request-state isolation.

These are not interchangeable tests. A provenance signature over a report would not make fabricated testing real. A gateway access token would not by itself verify a nested provider destination. A normal response status would not reveal cross-request decoder state. Reproducing the claimed effect, at the component where it occurs, is the common evidentiary standard. That also defines what remains unknown: Apex customer impacts, field misuse of LiteLLM defects and cross-client frequency for the vLLM bug were not established by these source records.