Skip to main content
Devin kann mit Ihren MongoDB-Daten so arbeiten wie ein Engineer mit einer schreibgeschützten Verbindungszeichenfolge: nachsehen, was Collections tatsächlich enthalten, herausfinden, warum eine Abfrage langsam ist, eine Migration in einer Sandbox-Datenbank durchspielen und einen PR öffnen. In dieser Anleitung richten Sie das mit Identitäten ein, die Sie eigens für Devin erstellen – so läuft Devin nie unter dem Konto eines Ihrer Engineers.
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 Owner zum Erstellen eines Dienstkontos; Project Owner für den Datenbanknutzer und die Zugriffslisten.
Devin
  • Berechtigung zum Bearbeiten des Umgebungs-Blueprints und zum Hinzufügen von Secrets.
  • Für die MCP-Varianten die Berechtigung Manage MCP Servers.
Netzwerk
  • Die IP-Adressen von Devin sind in der IP-Zugriffsliste des Projekts eingetragen (Schritt 1).
  • Wenn Sie eine Devin-Netzwerkrichtlinie verwenden, lassen Sie *.mongodb.net und cloud.mongodb.com zu, außerdem die Hosts, von denen der Blueprint Pakete installiert: pgp.mongodb.com und repo.mongodb.org (Option A) bzw. registry.npmjs.org und nodejs.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.
Die Liste enthält sowohl einzelne Adressen als auch einen CIDR-Bereich. Verwenden Sie --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:
Ohne --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.
Die Zeile Niemals ist vor allem bei Option B entscheidend. Wenn das Dienstkonto Datenbanknutzer anlegen kann, erstellt das Tool atlas-connect-cluster des MCP-Servers einen temporären Nutzer für den gesamten Cluster (readAnyDatabase bzw. readWriteAnyDatabase ohne --readOnly) und umgeht damit die datenbankspezifischen Rollen für devin-sessions. Dieser Nutzer bleibt 4 Stunden lang bestehen, sofern ihn das MCP-Disconnect-Tool nicht vorher löscht.

Schritt 3: Devin verbinden

Option A: CLI in einem Blueprint

  1. 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.

  1. Blueprint hinzufügen

Ersetzen Sie 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.
Schreiben Sie in initialize keine Anmeldedaten auf die Festplatte. Eine ~/.mongoshrc.js, eine ~/.config/atlascli/config.toml oder eine exportierte URI in ~/.bashrc landet im Snapshot und steht damit jeder künftigen Sitzung zur Verfügung.

  1. 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 offizielle mongodb-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.
  • --readOnly registriert keine Create-, Update- und Delete-Tools und lehnt Aggregationen ab, die $out oder $merge enthalten. 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.
  • --indexCheck lehnt Abfragen ab, deren Plan einen Collection-Scan vorsieht. Dies ist ein Performance-Guardrail: Schlägt explain selbst fehl, wird die Abfrage trotzdem ausgeführt.
Der Server erfordert Node ^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:
Verwenden Sie den schreibgeschützten Datenbank-Nutzer auch mit --readOnly. Devin kann mit demselben Nutzer auch mongosh "$MONGODB_URI" ausführen – die eigentliche Schutzgrenze bilden daher die Rollen des Nutzers.

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.
  1. 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.
  2. Erstellen Sie einen dedizierten Atlas-Nutzer für Devin mit GROUP_READ_ONLY und GROUP_DATA_ACCESS_READ_ONLY – ausschließlich in Projekten, die er lesen darf. GROUP_DATA_ACCESS_READ_ONLY gewährt Lesezugriff auf Dokumente in allen Datenbanken des Projekts und ist damit weiter gefasst als der Nutzer devin-sessions.
  3. Installieren Sie das Plugin und führen Sie den OAuth-Login einmalig unter Customize > MCPs durch – angemeldet als dieser Nutzer, nicht als Sie selbst.
  4. 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, die apt 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.
Code wird weiterhin über Pull-Requests ausgeliefert. Devin liest die Produktionsdaten, um das Problem zu verstehen, und validiert die Korrektur in devin_dev; die Migration oder der Index gelangt über Ihren regulären Review-Prozess in die Produktion.

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:
Berechtigungsgrenze. Der erste Insert sollte fehlschlagen (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:
Prüfen Sie, ob die Rollen in 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.

Support

Informationen zu Atlas finden Sie in der Atlas-Sicherheitsdokumentation und in der Dokumentation zum MongoDB MCP-Server. Bei Fragen zu Devin wenden Sie sich an support@cognition.ai oder an Ihr Account-Team.