Security & Patterns

This section outlines the guardrails and usage patterns that keep MongoDB tools safe for production. The main risks are overly broad filters, unbounded updates or deletes, and large result sets that return too much data.

Guardrails & Collection Scope

Keep operations inside approved databases and collections. That matters most for:

• Find and Count, which can scan large data sets.
• Insert and Update, which can change production data.
• Delete, which can remove data permanently.

Collection Scope Must Be Enforced

Unvalidated filters or collection names can expose unintended data. Enforce allowlists, collection-level permissions, and input validation before allowing runtime substitution.

Query and Update Safety

MongoDB filters and update documents are powerful, so keep them narrow and predictable.

Recommended practices:

• Use allowlists for filter keys, especially for mutation tools.
• Prefer exact-key filters (for example, _id) for update or delete actions.
• Require $set-only updates when you want to prevent document replacement.
• Avoid $where or unbounded logical conditions unless you control the inputs.

Fully Dynamic AI Queries

The special {{query}} argument allows the AI to generate the full MongoDB filter or pipeline at runtime from natural language. This is useful when you do not have a fixed tool for a one-off question, but it increases risk because the AI controls the entire query shape.

Use case example: If a user asks, "Show the 10 newest paid orders from enterprise customers," the AI can build a filtered query with a sort and a limit without a pre-defined tool.

Security Risks of Dynamic Queries

Using {{query}} gives the AI broad control over filters and pipeline stages. Only enable it with strict collection allowlists, key allowlists, and a database role that limits reads and writes.

Action-Specific Safety

Find and Count

Discovery tools should be bounded carefully.

• Use a conservative limit to keep result sets small.
• Add a projection so only needed fields are returned.
• Keep filters narrow and indexed to avoid slow scans.

Insert and Update

Write actions are where data integrity matters most.

• Validate required fields before inserts.
• Use $set updates to avoid replacing entire documents.
• Require filters for updates; never allow an empty filter for mutation tools.

Delete

Deletes are high-risk and should be used sparingly.

• Restrict delete tools to service accounts with narrow scope.
• Require explicit filters and block empty filters.
• Prefer delete_one over delete_many unless the use case is tightly controlled.

Performance Optimization

Pattern	Description	Benefit
Indexed Filters	Index fields used in filters.	Reduces query latency.
Limit Clauses	Set a limit for find results.	Prevents large result sets.
Narrow Projections	Return only needed fields.	Reduces payload size.
Bounded Updates	Require filters for all updates.	Avoids full-collection writes.

Protocol Limitations

• Large binary fields can exceed response size limits if returned in queries.
• Long-running queries may time out if filters are unbounded or unindexed.