Hallucination Attacks in Axum with Mongodb

Hallucination attacks in an Axum service that uses MongoDB as a backend occur when an application returns fabricated or misleading data while presenting it as authoritative. This typically arises when the application layer synthesizes responses rather than strictly reflecting what is stored in the database. In Axum, handlers often deserialize incoming requests, build a query, and return results; if the handler fills missing fields or joins data from multiple sources without strict source attribution, it can invent content.

With MongoDB, common patterns that enable hallucination include:

• Returning enriched documents where missing fields are generated (e.g., computed or default values) instead of being transparently absent.
• Performing in-application joins or lookups and merging results without indicating which parts came from the database versus which were constructed by the handler.
• Using broad queries (e.g., { "_id": id }) that may not match any document, and then the handler fabricates a plausible response instead of returning a 404 or an error.

In the context of API security checks run by middleBrick, hallucination maps to the Property Authorization and Input Validation categories. If an endpoint returns synthetic data, it may expose information that should remain hidden or provide incorrect data to clients, violating integrity expectations. MiddleBrick’s active prompt injection testing and output scanning help detect whether responses include unauthorized or fabricated content, such as injected instructions or unexpected PII/code in LLM-style outputs when the API is used as a backend for AI-assisted clients.

Because Axum is a Rust web framework, type safety and pattern matching reduce some risks, but they do not prevent logical hallucination. For example, an endpoint could pattern-match Some(doc) and None, returning a constructed document in the None case. This constructed content may be consistent and well-typed, yet it is not sourced from MongoDB, creating a hallucination. MiddleBrick’s OpenAPI/Swagger spec analysis cross-references definitions with runtime behavior; if the spec promises a strict schema but runtime responses include additional fields or altered structures, this discrepancy is flagged as a potential authorization or data exposure issue.

Attackers may exploit hallucination to infer internal logic, extract fabricated data as if it were real, or manipulate downstream AI consumers that trust the API’s output. For instance, if an Axum handler merges MongoDB results with hardcoded suggestions, an LLM consuming this API might treat suggestions as factual, leading to misuse or cost exploitation. middleBrick’s LLM/AI Security checks specifically target such scenarios by probing for source confusion and output integrity issues.

To prevent hallucination when using MongoDB with Axum, ensure that responses are strictly sourced and that synthetic construction is either avoided or clearly marked. Below are concrete practices and code examples.

1. Explicitly handle missing documents

Do not fabricate a document when MongoDB returns None. Instead, return an appropriate 404 or an error payload. This keeps the API truthful and aligns with property authorization checks.

use axum::{http::StatusCode, response::IntoResponse};
use mongodb::{bson::doc, Collection};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Item {
    id: String,
    name: String,
    // Do not add fabricated fields here
}

async fn get_item_by_id(collection: Collection, id: String) -> Result {
    let filter = doc! { "_id": id };
    match collection.find_one(filter, None).await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))? {
        Some(doc) => Ok(doc),
        None => Err((StatusCode::NOT_FOUND, "Item not found".to_string())),
    }
}

2. Avoid in-application joins that blend sources without attribution

If you need to combine data, preserve source markers so clients can distinguish which fields come from MongoDB and which are locally derived.

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct DbItem {
    id: String,
    value: String,
}

#[derive(Debug, Serialize, Deserialize)]
struct EnrichedItem {
    source: String, // "db" or "computed"
    id: String,
    value: String,
    computed_field: Option, // only present if derived
}

fn enrich_from_db(db_item: DbItem) -> EnrichedItem {
    EnrichedItem {
        source: "db".to_string(),
        id: db_item.id,
        value: db_item.value,
        computed_field: None,
    }
}

fn compute_supplemental(id: &str) -> EnrichedItem {
    EnrichedItem {
        source: "computed".to_string(),
        id: id.to_string(),
        value: "default".to_string(),
        computed_field: Some("derived_value".to_string()),
    }
}

3. Validate and restrict returned fields against the OpenAPI schema

Ensure your handler does not inject extra fields that are not defined in the schema. If you must add computed fields, document them explicitly and mark them as non-source data. middleBrick’s spec analysis will highlight undocumented fields in responses.

4. Use strict query filters and avoid broad scans

Always use precise filters and projection to limit returned data. Do not rely on client-supplied field lists to decide what to return; validate against a known schema to prevent injection of unexpected content.

let projection = doc! { "name": 1, "value": 1, "_id": 0 };
let opts = mongodb::options::FindOptions::builder().projection(projection).build();