MongoDB-Sicherheit für KI-Agenten — dropDatabase blockieren, Runaway Aggregations gaten
MongoDB-Sicherheit für KI-Agenten konzentriert sich auf Collection-Writes, strukturelle Änderungen und Aggregation-Muster. FutrixData inspiziert Mongo-Operationen nach Typ (find, aggregate, updateMany, dropDatabase) und nutzt explain-Output, um Collection-Scans abzufangen, bevor Gigabytes in den Agenten-Kontext fließen.
MongoDB-Risikofläche im KI-Kontext
MongoDB-Risiko sieht nicht aus wie SQL. Die gefährlichen Operationen sind Collection-Drops, Rolle-Grants, Aggregation-Stages, die in andere Collections schreiben ($merge, $out), und unbegrenzte find-Aufrufe, die die gesamte Collection in den Agenten-Kontext materialisieren.
FutrixData parst Mongo-Operationen sowohl in JSON- als auch in Shell-Syntax — db.users.drop() und { "drop": "users" } lösen zur selben Regel auf.
Eingebaute MongoDB-Regeln
| Operation | Standardaktion |
|---|---|
find, aggregate, count | allow |
insertOne, insertMany, updateOne, updateMany, replaceOne, deleteOne, deleteMany | warn |
Cross-Collection-Aggregationen ($lookup, $unionWith) | warn |
Aggregationen mit $merge oder $out | require_approval |
renameCollection, collMod, dropIndexes | require_approval |
drop, dropDatabase | block |
createUser, dropUser, grantRolesToUser | block |
Vorgelagerte Explain-Probes
Für find und aggregate führt FutrixData explain aus und prüft:
- Ob ein Collection-Scan stattfindet.
- Ob die tatsächliche Document-Scan-Zahl den Schwellenwert überschreitet.
- Ob ein blockierender Sort oder komplexer Access-Pfad vorliegt.
Eine Query, die ein indiziertes Feld trifft, bleibt bei low risk; dieselbe Query mit einem regex auf einem nicht-indizierten Feld wird auf medium eskaliert.
Beispiele für Regeln pro Collection
- Gewöhnliche Inserts auf
eventsin der Produktion erlauben; jedes Update aufuserserfordert Approval. $outaufaudit_logsunabhängig von der Quelle blockieren.- Document-Scan-Schwelle auf der Staging-Kopie lockern.
Beispiele
// Agent attempts:
db.users.drop()
// FutrixData response:
{ "ok": false, "risk": "block", "rule": "mongo.drop_collection", "audit_id": "audit_01HQ8N..." }// Agent attempts:
db.events.aggregate([
{ $match: { kind: "purchase" } },
{ $out: "purchases_summary" }
])
// FutrixData response:
{ "ok": false, "risk": "require_approval", "rule": "mongo.aggregate_writes_other_collection" }Häufig gestellte Fragen
Unterstützt FutrixData Replica Sets und Sharded Clusters?
Ja. FutrixData verbindet sich über den Standard-MongoDB-Treiber — alles, was der MongoDB Driver unterstützt (Replica Sets, Sharded Clusters, MongoDB Atlas), funktioniert gleich. Die Regelauswertung läuft in FutrixData; Explain-Probes nutzen dieselbe Verbindung wie die echte Query.
Was ist mit <code>$where</code> (serverseitiges JavaScript)?
Aggregationen und finds, die $where enthalten, werden auf warn oder höher gekennzeichnet. Die Regel ist pro Collection konfigurierbar — Sie können $where gegen Produktionsquellen hart blockieren und auf Dev erlauben.
Kann ich Regeln pro Collection scopen?
Ja. Scope kann ein Datenbanktyp (alles MongoDB), eine spezifische Datenquellen-Instanz (nur prod-mongo) oder eine spezifische Collection sein. Regeln mit präziserem Scope rangieren über breiteren.
Funktioniert das mit MongoDB Atlas?
Ja. FutrixData behandelt Atlas wie jeden anderen MongoDB-Endpunkt — Connection-String rein, maskierte Ergebnisse raus. Atlas-IP-Allowlists müssen den FutrixData-Host enthalten (oder, bei Self-Hosting, Ihren Netzwerk-Egress).
Performance-Overhead?
Statische Regelauswertung sind Mikrosekunden. Explain-Probes fügen einen zusätzlichen Round-Trip auf Reads hinzu, bei denen der Access-Pfad zählt. Writes werden statisch ausgewertet — keine Probe.
Probieren Sie FutrixData mit Ihrer eigenen Datenbank aus
Kostenlose Desktop-App für macOS, Windows und Linux. Self-hosted Enterprise Edition für produktive Deployments.