> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Sicherheitsprofile > Definieren Sie wiederverwendbare Devin-Sicherheitsprofile, die den Netzwerk-, MCP-, Git- und GitHub-CLI-Zugriff beschränken, und weisen Sie sie Organisationen, Automatisierungen und Sitzungen zu. Mit Sicherheitsprofilen können Sie wiederverwendbare Gruppen von Sicherheitseinschränkungen definieren — Netzwerkzugriff, MCP-Zugriff, Git-Zugriff und GitHub-CLI-Anmeldedaten — und sie auf Devin-Sitzungen in Ihrer gesamten Organisation anwenden. Anstatt Einschränkungen für jede Sitzung einzeln zu konfigurieren, erstellen Admins benannte Profile einmal und weisen sie auf der jeweils passenden Ebene zu: als organisationsweiten Standard, für eine bestimmte Automatisierung oder für eine einzelne Sitzung. Enterprise-Kunden können Profile außerdem mit allen Organisationen teilen und sie als verbindliche Mindestvorgabe durchsetzen, die auf niedrigeren Ebenen von niemandem gelockert werden kann.
## Einschränkungen in einem Profil
Ein Profil ist eine benannte Sammlung von Einschränkungen. Jede Einschränkung ist optional — ein Profil wirkt sich nur auf die Settings aus, die darin konfiguriert sind.
### Netzwerkrichtlinie
Eine Netzwerkrichtlinie ist eine Allowlist von Zielen, die von der Maschine der Sitzung erreichbar sein dürfen. Alle anderen ausgehenden Verbindungen werden blockiert. Allowlist-Einträge können sein: * **Hostnamen** mit `*`-Wildcards (z. B. `*.github.com`, `registry.npmjs.org`). Ein `*` steht für eine beliebige Zeichenfolge, einschließlich Punkten. * **IPv4-/IPv6-CIDR-Bereiche** (z. B. `10.0.0.0/8`). Die Einschränkung gilt für jeden Netzwerkzugriff aus der Sitzung — also für Shell-Befehle, Browsing, Paketinstallationen und Skripte gleichermaßen. Devin erkennt, wenn es unter einer eingeschränkten Netzwerkrichtlinie ausgeführt wird: Es kann die aktuelle Allowlist einsehen und fordert Zugriff an, wenn es wegen eines fehlenden Ziels blockiert wird. Wird die Anfrage genehmigt, wird das Ziel für diese Sitzung hinzugefügt (vorbehaltlich eines verbindlichen Rahmens — siehe [Durchsetzung](#mandatory-vs-recommended-enforcement)). Ziele, die Devin zum Funktionieren benötigt (z. B. der Git-Proxy für den Zugriff auf Ihre verbundenen Repositories), sind automatisch erlaubt.
### MCP-Zugriff
Standardmäßig können Sitzungen jeden in Ihrer Organisation installierten [MCP server](/de/work-with-devin/mcp) verwenden. Ein Profil kann dies mit **einer Allowlist von MCP-Servern** einschränken — Sitzungen, für die das Profil gilt, können nur die aufgeführten Server verwenden. Der MCP-Zugriff wird unabhängig von der Netzwerkrichtlinie verwaltet: Sie müssen die Adresse eines MCP-Servers **nicht** zur Netzwerk-Allowlist hinzufügen. Server, die durch das Profil zugelassen sind, sind automatisch erreichbar, und Server, die durch das Profil ausgeschlossen sind, bleiben unabhängig von der Netzwerkrichtlinie nicht nutzbar.
### Devin MCP-Zugriff
Sitzungen haben außerdem über das integrierte Devin MCP Zugriff auf Devins eigene Verwaltungstools — zum Erstellen und Benachrichtigen untergeordneter Sitzungen, zum Bearbeiten von Knowledge und Playbooks, zum Verwalten von Zeitplänen und mehr. Ein Profil kann diesen Funktionsumfang mit **Devin MCP schreibgeschützt** einschränken: Sitzungen, die diesem Profil unterliegen, können Devin-Ressourcen weiterhin lesen (Sitzungen auflisten, Knowledge nachschlagen, Playbooks einsehen), aber keine Schreibvorgänge wie das Erstellen von Sitzungen oder das Bearbeiten von Knowledge ausführen.
### Git-Zugriffsstufe
Legt fest, was die Sitzung mit Ihren verbundenen Repositories tun kann: | Ebene | Was Devin tun kann | | -------------------- | --------------------------------------------------------------------------- | | **schreibgeschützt** | Repositories klonen und abrufen, aber keine Branches pushen oder PRs öffnen | | **Full** | Repositories wie gewohnt klonen, abrufen, pushen und PRs öffnen |
### GitHub-CLI-Token
Zusätzlich zu den grundlegenden Git-Operationen, die durch die Git-Zugriffsstufe abgedeckt sind, kann Devins Maschine einen GitHub-CLI-Token (`gh`) enthalten, mit dem Devin GitHub-Funktionen direkt über die GitHub-API nutzen kann. Ein Profil kann **den GitHub-CLI-Token entfernen**: Von diesem Profil gesteuerte Sitzungen können weiterhin über Devins Git-Integration mit Ihren Repositorys arbeiten, jedoch keine direkten GitHub-API-Aufrufe an GitHub durchführen. Ein Profil darf den Token nur behalten, wenn es auch **Full** Git-Zugriff gewährt und, falls es eine Netzwerkrichtlinie festlegt, `api.github.com` erlaubt. Beide Bedingungen werden beim Speichern des Profils überprüft.
## Wo Profile abgelegt sind
Profile gibt es in zwei Geltungsbereichen: * **Organisationsprofile** werden unter **Settings → Anpassung → Sicherheitsprofile** erstellt und können nur innerhalb dieser Organisation verwendet werden. * **Enterprise-Profile** (nur für Enterprise-Konten) werden unter **Enterprise-Settings → Devin → Sicherheitsprofile** erstellt und können von jeder Organisation im Enterprise verwendet werden. Organisationen können ein Enterprise-Profil für ihre Sitzungen, Automatisierungen oder ihren Organisationsstandard auswählen, aber nur Enterprise-Admins können das Profil selbst bearbeiten. Profilnamen müssen innerhalb ihres Geltungsbereichs eindeutig sein. Jedes Profil hat außerdem eine [Durchsetzungsstufe](#mandatory-vs-recommended-enforcement), die festlegt, ob es von untergeordneten Ebenen überschrieben werden kann.
## Woran Sie ein Profil binden können
Ein Profil wird wirksam, wenn es an eine Ressource *gebunden* wird. Bindungen bilden eine Hierarchie – von der allgemeinsten bis zur spezifischsten Ebene: 1. **Enterprise-Standard** — gilt für neue Sitzungen in jeder Organisation im Enterprise. 2. **Organisationsstandard** — gilt für neue Sitzungen in dieser Organisation. 3. **Automatisierungsstandard** — gilt für Sitzungen, die von [Automatisierungen](/de/product-guides/automations) in dieser Organisation gestartet werden, und überschreibt für diese Sitzungen den Organisationsstandard. Wird auf derselben Settings-Seite für Sicherheitsprofile festgelegt. 4. **Automatisierung** — gilt für Sitzungen, die von dieser spezifischen Automatisierung gestartet werden, und überschreibt den Automatisierungsstandard. Wird im Editor der Automatisierung festgelegt. 5. **Sitzung** — wird für eine einzelne Sitzung beim Erstellen ausgewählt (über das Optionsmenü im Startdialog der Sitzung) oder später in den Settings der Sitzung geändert. Auf jeder Ebene können Sie eine von drei Optionen wählen: * **Vererben** (Standard) — keine eigene Vorgabe; die darüberliegende Ebene entscheidet. * **Ein Profil anpinnen** — Sitzungen auf dieser Ebene verwenden das ausgewählte Profil. * **Kein Profil** — expliziter Verzicht, sodass Sitzungen auf dieser Ebene ohne Einschränkungen ausgeführt werden, selbst wenn eine darüberliegende Ebene einen empfohlenen Standard festlegt. Wenn eine Sitzung startet, durchläuft Devin die Hierarchie von oben nach unten: Die spezifischste Bindung hat Vorrang, sofern nicht weiter oben ein verbindliches Profil festgelegt ist, das strengere Vorgaben erzwingt (siehe unten). Von anderen Sitzungen gestartete Sitzungen (untergeordnete Sitzungen) unterliegen derselben Kette wie ihre übergeordnete Sitzung, sodass sich Einschränkungen nicht durch das Delegieren von Arbeit umgehen lassen.
### Wann Änderungen wirksam werden
Eine Sitzung ermittelt ihr maßgebliches Profil zu den Zeitpunkten, an denen sie startet: wenn sie erstmals erstellt wird und jedes Mal, wenn sie aus dem Ruhezustand aufwacht oder neu gestartet wird. Änderungen am Inhalt eines Profils oder an einer Bindung (einer Standardzuweisung, dem Anpinnen einer Automatisierung oder einer Sitzungsauswahl) werden **nicht** automatisch an bereits laufende Sitzungen weitergegeben — eine laufende Sitzung behält die Einschränkungen bei, die sie bei ihrem letzten Aufwachen ermittelt hat. Für neue Sitzungen werden Änderungen sofort wirksam, und für bestehende Sitzungen dann, wenn sie das nächste Mal fortgesetzt werden. Jedes Profil hat eine Durchsetzungsstufe: Ein empfohlenes Profil ist ein Standard, keine Vorgabe. Jede Person kann (mit der entsprechenden Berechtigung) auf einer niedrigeren Ebene ein anderes Profil anpinnen oder ganz darauf verzichten. Verwenden Sie empfohlene Profile, um Teams eine sinnvolle Ausgangskonfiguration zu geben und gleichzeitig die nötige Flexibilität zu bewahren.
### Verbindlich
Ein verbindliches Profil ist eine Untergrenze, die auf niedrigeren Ebenen nicht umgangen werden kann: * **Das Abwählen hat keine Wirkung.** Eine Auswahl von „kein Profil“ unterhalb eines verbindlichen Profils wird ignoriert. * **Auswahlen auf niedrigeren Ebenen können nur weiter einschränken, niemals lockern.** Wenn eine niedrigere Ebene ein anderes Profil anpinnt, werden die beiden als *Schnittmenge* kombiniert: * Netzwerk-Allowlists werden auf die Ziele eingeschränkt, die von **beiden** Profilen erlaubt sind. * MCP-Allowlists werden auf die Server eingeschränkt, die von beiden erlaubt sind. * Beim Git-Zugriff gilt die **geringere** Berechtigung (schreibgeschützt hat Vorrang vor Vollzugriff). * Der Devin MCP-Zugriff ist schreibgeschützt, wenn **eines** der beiden Profile ihn auf schreibgeschützt setzt. * Das GitHub-CLI-Token wird entfernt, wenn **eines** der beiden Profile es entfernt. * **Änderungen während einer Sitzung werden begrenzt.** Netzwerkzugriff, der während einer Sitzung gewährt wird (z. B. durch Genehmigung von Devins Anfrage für eine neue Domain), wird mit der Richtlinie des verbindlichen Profils als Schnittmenge kombiniert, sodass einer Sitzung niemals Zugriff über das hinaus gewährt werden kann, was das verbindliche Profil erlaubt. Zum Beispiel kann ein Enterprise-Konto ein verbindliches Profil mit einer Netzwerkrichtlinie, die `*.internal.example.com` erlaubt, als Enterprise-Standard festlegen. Organisationen können dann ihre eigenen Profile darüberlegen, um bestimmte Teams oder Workflows weiter einzuschränken — aber keine Organisation, keine Automatisierung und keine Sitzung kann den Zugriff über die Enterprise-Richtlinie hinaus erweitern.
## Berechtigungen und Governance
Die Verwaltung von Profilen wird durch die separate Berechtigung **Sicherheitsprofile verwalten** gesteuert, unabhängig von der allgemeinen Verwaltung von Settings. Sie gibt es auf zwei Ebenen, die jeweils unabhängig voneinander vergeben werden: | Berechtigungsebene | Was sie erlaubt | Standardmäßig zugewiesen an | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | | Organisation | Organisationsprofile erstellen, bearbeiten und löschen; den Org- und Automatisierungs-Standard festlegen; Profile an Automatisierungen und Sitzungen anpinnen | Org-Admins | | Enterprise | Enterprise-Profile erstellen, bearbeiten und löschen; den Enterprise-Standard festlegen | Enterprise-Admins | Beide Ebenen dieser Berechtigung können [benutzerdefinierten Rollen](/de/enterprise/security-access/custom-roles) zugewiesen werden, sodass Sie die Verwaltung von Sicherheitsrichtlinien delegieren können (zum Beispiel an ein Sicherheitsteam), ohne vollständige Admin-Rechte zu vergeben. Member ohne diese Berechtigung können Profile weder auflisten noch auswählen oder ändern — ihre Sitzungen folgen einfach dem ermittelten Standard — aber jede Person kann sehen, ob ihre Sitzung von einem Profil gesteuert wird und welchen Netzwerkzugriff sie hat.
## Sicherheitsprofile einrichten
1. **Erstellen Sie ein Profil.** Gehen Sie zu **Settings → Anpassung → Sicherheitsprofile** (oder **Enterprise-Settings → Devin → Sicherheitsprofile** für ein unternehmensweites Profil), erstellen Sie ein Profil und konfigurieren Sie dessen Sicherheitseinstellungen und Durchsetzungsstufe. 2. **Legen Sie einen Standard fest.** Binden Sie das Profil als Organisationsstandard (oder als Enterprise-Standard), damit neue Sitzungen es automatisch übernehmen. 3. **Pinnen Sie es bei Bedarf an.** Überschreiben Sie den Standard für bestimmte Automatisierungen — zum Beispiel mit einem strengeren Profil für eine Automatisierung, die auf sensible Systeme zugreift — oder für einzelne Sitzungen beim Erstellen. 4. **Verschärfen Sie es im Laufe der Zeit.** Beginnen Sie mit einem empfohlenen Profil, um die Auswirkungen zu beobachten, und stellen Sie es dann auf verbindlich um, sobald Ihre Allowlists die legitimen Anforderungen Ihrer Teams abdecken.
## Automatisierungen und Profile
Automatisierungen können eigene Netzwerkrichtlinien und MCP-Auswahlen haben. Sie bilden **ausschließlich einschränkende Schichten** über dem maßgeblichen Profil – von einer Automatisierung gestartete Sitzungen erhalten nur Zugriff auf Netzwerkziele und MCP-Server, die sowohl von der Automatisierung als auch vom Profil erlaubt sind. Eine Automatisierung kann den Zugriff des Profils also niemals erweitern. Die Automatisierungsschicht wird bei jedem Start und jedem Aufwachen einer Sitzung live ermittelt. Änderungen an der Netzwerkrichtlinie einer Automatisierung werden daher wirksam, ohne dass ihre Sitzungen neu erstellt werden müssen.
## Outposts und Profile
Sitzungen, die auf [Devin Outposts](/de/cloud/outposts/overview) ausgeführt werden, beziehen ihr maßgebliches Profil über dieselbe Bindungskette wie Cloud-Sitzungen. Die Einschränkungen, die Devin in seiner Cloud durchsetzt – die MCP-Zulassungsliste, der schreibgeschützte Zugriff für Devin MCP, die Git-Zugriffsstufe und das Entfernen von GitHub-CLI-Tokens –, gelten für Outpost-Sitzungen genauso wie für Cloud-Sitzungen. Die **Netzwerkrichtlinie** unterscheidet sich jedoch. Devin setzt die Netzwerk-Allowlist einer Sitzung auf Maschinenebene in von Devin verwalteten VMs durch. Da ein Outpost-Worker jedoch auf Infrastruktur läuft, die Sie betreiben, installiert Devin keine Firewallregeln auf Ihren Maschinen. Stattdessen wird die effektive Netzwerkrichtlinie jeder Sitzung in der Warteschlange über die [Outposts API](/de/cloud/outposts/reference) als `spec.network_policy` an Ihren Orchestrator übermittelt (ob die Richtlinie aktiviert ist sowie die zulässigen Hostnamen und CIDRs). Die Durchsetzung – zum Beispiel mit einem Egress-Proxy pro Sitzung, einer Kubernetes-`NetworkPolicy` oder VM-Firewallregeln – liegt in der Verantwortung des Outpost-Betreibers. Devin sieht die Netzwerk-Allowlist weiterhin und fordert wie gewohnt Zugriff auf nicht freigegebene Ziele an. Die Genehmigung einer Anfrage aktualisiert jedoch nur die Sitzungsrichtlinie in Devin; Ihr Netzwerk wird dadurch nicht automatisch geändert. `spec.network_policy` wird erfasst, wenn die Sitzung für einen Outpost in die Warteschlange gestellt wird, und aktualisiert, wenn sie erneut eingereiht wird, zum Beispiel nachdem die Sitzung in den Ruhemodus wechselt und wieder aufwacht. Lesen Sie die Richtlinie daher erneut über die API ab, statt davon auszugehen, dass sie unverändert bleibt. Wenn Sie sich bei der Netzwerkrichtlinie eines verbindlichen Profils auf eine strikte Grenze verlassen, stellen Sie sicher, dass Ihre Outpost-Infrastruktur `spec.network_policy` für jede von ihr ausgeführte Sitzung durchsetzt. Andernfalls haben Sitzungen auf Outposts denselben Netzwerkzugriff wie Ihre Maschinen.