Alles bleibt in Ihrem Atlas-Konto: ein Datenbanknutzer, ein Dienstkonto, MongoDB-Tools, die über einen Umgebungs-Blueprint installiert werden, und optional ein MCP-Server. Beginnen Sie mit minimalen Rechten (schreibgeschützter Zugriff auf die Produktion) und erweitern Sie die Rollen später. Die Rollen legen die Grenzen fest, und Sie ändern sie direkt in Atlas, ohne Devin anpassen zu müssen.
Zwei Ebenen, zwei Identitäten
Ein Datenbanknutzer kann die Atlas Administration API nicht aufrufen, und ein Dienstkonto kann über die API keine Dokumente lesen. Die meisten Teams starten zunächst nur mit der Datenebene und ergänzen das Dienstkonto, sobald Devin den Performance Advisor oder Slow-Query-Logs benötigt (dedizierte Cluster, ab M10). Zwei Hinweise:
- Ein Dienstkonto, das Datenbanknutzer anlegen darf (
GROUP_OWNER,GROUP_DATABASE_ACCESS_ADMIN), kann sich selbst eine Identität auf der Datenebene ausstellen. Genau das macht der MongoDB-MCP-Server, wenn er eine Verbindung zu einem Cluster herstellen soll (Option B). - Slow-Query-Daten enthalten die tatsächlichen Werte aus den Abfragen.
Verbindungsart für Devin wählen
Alle drei Wege nutzen denselben Netzwerkzugriff (Schritt 1) und dieselben Identitäten (Schritt 2); sie unterscheiden sich darin, welche Zugangsdaten Devin selbst erhält.Warum Devin mit MongoDB verbinden?
- Das Schema steckt in den Dokumenten. MongoDB hat kein
information_schema, und Mongoose- oder Prisma-Modelle weichen mit der Zeit von den tatsächlich gespeicherten Daten ab. Devin zieht Stichproben aus den Live-Collections und arbeitet mit der realen Struktur. - Langsame Abfragen werden in einer einzigen Sitzung vollständig behoben. Devin liest den Performance Advisor und das Slow-Query-Log, führt
explain()auf der echten Collection aus, findet den Code, der die Abfrage absetzt, und öffnet einen PR mit dem Fix und dem vorgeschlagenen Index. - Die Rollen des Datenbanknutzers bestimmen, worauf Devin zugreifen darf. Starten Sie in der Produktion schreibgeschützt und nutzen Sie eine
devin_dev-Sandbox für Schreibvorgänge. Jede Aktion wird in den Atlas-Logs unter Devins eigener Identität protokolliert.
Voraussetzungen
Atlas- Ein Projekt mit einem Cluster.
Organization Ownerzum Erstellen eines Dienstkontos;Project Ownerfür den Datenbanknutzer und die Zugriffslisten.
- Berechtigung zum Bearbeiten des Umgebungs-Blueprints und zum Hinzufügen von Secrets.
- Für die MCP-Varianten die Berechtigung Manage MCP Servers.
- Die IP-Adressen von Devin sind in der IP-Zugriffsliste des Projekts eingetragen (Schritt 1).
- Wenn Sie eine Devin-Netzwerkrichtlinie verwenden, lassen Sie
*.mongodb.netundcloud.mongodb.comzu, außerdem die Hosts, von denen der Blueprint Pakete installiert:pgp.mongodb.comundrepo.mongodb.org(Option A) bzw.registry.npmjs.orgundnodejs.org(Option B). Der Treiber verbindet sich über Port 27017, nicht über 443. Da Richtlinieneinträge Hostnamen oder CIDRs sind, muss kein Port angegeben werden. Für Snapshot-Builds gilt dieselbe Richtlinie.
Schritt 1: Netzwerkzugriff freigeben
Atlas lehnt Verbindungen von IPs ab, die nicht in der IP-Zugriffsliste des Projekts stehen. Fügen Sie die unter IP-Allowlisting aufgeführten IPs hinzu – nicht aus dem Gedächtnis. Dedizierte Mandanten haben eigene ausgehende Verbindungen (Egress); stimmen Sie sich dazu mit Ihrem Account-Team ab.--type ipAddress für einzelne Adressen und --type cidrBlock für den Bereich.
Wenn Ihre Organisation eine API-Zugriffsliste für Dienstkonten vorschreibt, fügen Sie dieselben IP-Adressen in Atlas auf der Seite des Dienstkontos hinzu. Aufrufe von einer IP-Adresse, die nicht in der Liste steht, schlagen mit 403 fehl.
Schritt 2: Identitäten für Devin erstellen
Datenbanknutzer
Lesezugriff auf Produktionsdatenbanken, Lese-/Schreibzugriff in einer Sandbox, beschränkt auf namentlich festgelegte Cluster:--scope kann der Nutzer auf alle Cluster im Projekt zugreifen. Verwenden Sie eine benutzerdefinierte Datenbankrolle, wenn sich die gewünschte Einschränkung mit den integrierten Rollen nicht abbilden lässt. Generieren Sie das Passwort mit einem Passwort-Manager und achten Sie darauf, dass es nicht im Shell-Verlauf landet. Kopieren Sie die Verbindungszeichenfolge dieses Nutzers; geben Sie Devin nicht den Admin-Nutzer des Clusters.
Dienstkonto (nur wenn Devin die Control Plane benötigt)
Erstellen Sie es in Atlas unter Identity & Access > Applications auf Organisationsebene. Beginnen Sie mit Lesezugriff und wählen Sie für das Client-Secret die kürzeste Gültigkeitsdauer, die Ihr Rotationszyklus zulässt.Schritt 3: Devin verbinden
Option A: CLI in einem Blueprint
- Devin Secrets hinzufügen
Auf dem Tab Secrets des Blueprints:
Secrets werden pro Sitzung injiziert, daher ist beim Rotieren eines Werts kein Rebuild nötig. Die Atlas CLI liest Client-ID und Secret aus diesen Umgebungsvariablen, ein
atlas auth login entfällt also. Bei der ersten Verwendung legt sie ein Zugriffstoken in ~/.config/atlascli/config.toml im Cache ab. Innerhalb einer Sitzung ist das unproblematisch, erstellen Sie diese Datei aber niemals in initialize.
- Blueprint hinzufügen
jammy, falls Ihr Image nicht auf Ubuntu 22.04 basiert.
Der knowledge-Block ist wichtiger als die Installation: Ohne ihn führen Sitzungen atlas auth login aus (ein Browser-Ablauf, den niemand abschließen kann) oder fragen nach einer Verbindungszeichenfolge, die bereits in der Umgebung vorhanden ist.
- Snapshot erstellen
Speichern Sie den Blueprint, warten Sie auf den Status Success und starten Sie dann eine neue Sitzung. Bereits laufende Sitzungen verwenden weiterhin den alten Snapshot.
Option B: MongoDB-MCP-Server
Der offiziellemongodb-mcp-server läuft als lokaler Prozess innerhalb der Sitzung und verwendet die Identitäten aus Schritt 2. Damit seine Guardrails greifen, fügen Sie ihn als benutzerdefinierten MCP-Server hinzu (Customize > MCPs > Add MCP > Add custom MCP, Transport STDIO) und nicht über das mongodb-Plugin aus dem Marketplace, dessen Manifest --readOnly und --indexCheck nicht bereitstellt.
Pinnen Sie
<version> auf ein Release an, das Sie getestet haben, denn npx lädt das Paket bei jedem Sitzungsstart neu herunter. Mit dem schreibgeschützten Dienstkonto aus Schritt 2 gibt atlas-connect-cluster 401 zurück. Devin greift stattdessen über die preconfigured-Verbindung aus MDB_MCP_CONNECTION_STRING auf die Daten zu – das ist so vorgesehen.
--readOnlyregistriert keine Create-, Update- und Delete-Tools und lehnt Aggregationen ab, die$outoder$mergeenthalten. Ohne diese Option werden solche Aggregationen nach einer Bestätigungsabfrage ausgeführt – oder ganz ohne Bestätigung, wenn der MCP-Client keine Abfragen unterstützt. Verwenden Sie die Option für alles, was auf die Produktionsumgebung zugreift.--indexChecklehnt Abfragen ab, deren Plan einen Collection-Scan vorsieht. Dies ist ein Performance-Guardrail: Schlägtexplainselbst fehl, wird die Abfrage trotzdem ausgeführt.
^20.19.0 || ^22.13.0 || >=24.0.0. Prüfen Sie node --version in einer Sitzung. Ist die Version älter oder befindet sich npx nicht im Pfad, den der MCP-Prozess sieht, fügen Sie Node zum Blueprint hinzu:
Option C: MongoDB Atlas-Plugin
Das MongoDB Atlas-Plugin verbindet Devin mit dem gehosteten MCP-Server von MongoDB (mcp.mongodb.com) und installiert die Agent-Skills von MongoDB. Devin agiert mit den Atlas-Rollen des Nutzers, der sich anmeldet – begrenzt durch den AI-Client-Zugriffsmodus der Organisation.
- Ein Organization Owner aktiviert den AI-Client-Zugriff (Organization Settings > App Connections) und setzt den Zugriffsmodus auf Read, damit keine Schreib-Tools registriert werden. Die Einstellung gilt für alle AI-Clients in der Organisation, nicht nur für Devin.
- Erstellen Sie einen dedizierten Atlas-Nutzer für Devin mit
GROUP_READ_ONLYundGROUP_DATA_ACCESS_READ_ONLY– ausschließlich in Projekten, die er lesen darf.GROUP_DATA_ACCESS_READ_ONLYgewährt Lesezugriff auf Dokumente in allen Datenbanken des Projekts und ist damit weiter gefasst als der Nutzerdevin-sessions. - Installieren Sie das Plugin und führen Sie den OAuth-Login einmalig unter Customize > MCPs durch – angemeldet als dieser Nutzer, nicht als Sie selbst.
- Pinnen Sie das Plugin an einen Commit an, sobald es funktioniert.
Der Datenverkehr stammt aus der gehosteten Infrastruktur von MongoDB und Devin, nicht aus der Sitzung. Die IP-Listen aus Schritt 1 und Ihre Netzwerkrichtlinie greifen daher nicht. Der Zugriff endet nach 7 Tagen Inaktivität oder 30 Tage nach der Anmeldung, je nachdem, was zuerst eintritt; melden Sie sich anschließend erneut an. Durch das Widerrufen des Zugriffs werden weder Datenbanknutzer noch andere vom Client erstellte Artefakte gelöscht – überprüfen Sie diese daher.
Rebuilds und Versions-Pinning
Der Blueprint installiert die Version, dieapt zum Build-Zeitpunkt bezieht, und bei Option B lädt npx mongodb-mcp-server bei jedem Start einer Sitzung neu herunter. Pinnen Sie beide an (mongodb-atlas-cli=<version>, mongodb-mongosh=<version>, mongodb-mcp-server@<version>), sobald sie funktionieren, und aktualisieren Sie die Versionen gezielt. Das Rotieren eines Secrets erfordert keinen Rebuild, das Ändern eines installierten Tools dagegen schon.
Schritt 4: Berechtigungen festlegen
Die Authentifizierung legt fest, wer Devin ist; Datenbank- und Atlas-Rollen legen fest, worauf Devin zugreifen darf. MCP-Flags und Knowledge-Anweisungen sind lediglich zusätzliche Hilfsmittel, nicht die eigentliche Sicherheitsgrenze.
Für Explore genügt für vorgeschlagene Indizes
GROUP_READ_ONLY (Abfragewerte werden maskiert zurückgegeben). Für die Liste langsamer Abfragen, Beispiel-Abfragewerte und Log-Downloads ist zusätzlich GROUP_DATA_ACCESS_READ_ONLY erforderlich; die in der Hilfe der Atlas CLI geforderte Rolle GROUP_DATA_ACCESS_READ_WRITE wird nicht benötigt. Nur mit GROUP_READ_ONLY meldet das MCP-Tool atlas-get-performance-advisor „No slow query logs found“ statt 401 – ein leeres Ergebnis kann also auf ein Rollenproblem hindeuten.
Schritt 5: Überprüfen
Starten Sie eine neue Sitzung und bitten Sie Devin, Folgendes auszuführen: Konnektivität. Welcher Nutzer, welche Rollen und (falls konfiguriert) ob die Authentifizierung über die Atlas CLI funktioniert:not authorized on <prod-db> to execute command auf dedizierten Clustern, user is not allowed to do action [insert] on [<prod-db>.devin_probe] auf M0/Flex), der zweite sollte gelingen:
connectionStatus dem Profil entsprechen, das Sie erteilt haben; dass eine Verbindung offen ist, sagt allein wenig aus. Um den MCP-Server zu testen, bitten Sie Devin, über die MCP-Tools Datenbanken aufzulisten (dabei wird die Verbindung preconfigured verwendet) und anschließend ein Dokument einzufügen: Mit --readOnly gibt es kein insert-many-Tool, und eine Aggregation mit $out wird abgelehnt.
Fehlerbehebung
Einschränkungen
Gespeicherte Anmeldedaten sind erforderlich. Devins kurzlebiges OIDC-Token lässt sich derzeit nicht mit MongoDB verwenden, da die Administration API ausschließlich Secrets von Dienstkonten oder API-Schlüssel akzeptiert. Atlas Workload Identity Federation deckt zwar die Datenebene auf dedizierten Clustern ab, erfordert jedoch einen Token-Callback auf Treiberebene und wurde noch nicht mit Devins Issuer getestet. Wenn Sie es ausprobieren möchten, wenden Sie sich an Ihr Account-Team. Self-hosted MongoDB. Die Schritte für die Datenebene (Datenbanknutzer,MONGODB_URI, mongosh, MCP-Server) gelten unverändert. Ein Atlas-Dienstkonto und eine IP-Zugriffsliste gibt es hier nicht; der Netzwerkzugriff erfolgt über Ihr VPN oder Ihre eigene Allowlist.

