Wie lässt sich Xcode 27 AI Agent integrieren? Leitfaden zur Isolation für Unternehmen 2026

Apple dokumentiert für Xcode 27 drei getrennte Kontrollbereiche: den Zugriff externer Agenten auf Xcode Tools, die Berechtigungen für Agent-Befehle und die Verwaltung über MDM (externe Agenten in Xcode, Agent-Befehle und Tool-Berechtigungen, MDM-Verwaltung). Daraus folgt die wichtigste Entscheidung für den 20.08.2026: Öffnen Sie Xcode 27 AI Agent weder auf dem täglichen Entwicklerarbeitsplatz noch auf einem Produktionsknoten für Signaturen. Verwenden Sie stattdessen einen unabhängigen Apple-Silicon-Mac mit eigenem Konto, minimalen Befehlsrechten, getrennten Zugangsdaten und rücksetzbarem Arbeitsbereich. Erst nach Audit- und Build-Abnahme erweitern Sie den Einsatz projektweise.

Diese Anleitung ist für Sie relevant, wenn Sie die Zulassung von AI-Programmierwerkzeugen, den Zugriff auf Quellcode und externe Tools festlegen. Sie bauen eine Xcode-27-Testumgebung, verwalten entfernte Mac-Knoten oder verantworten die Sicherheitsfreigabe für Entwicklungsprozesse. Auch für technische Leiter, die den Bedarf an isolierten Knoten anhand realer Build- und Rücksetztests bewerten müssen, ist das Modell gedacht.

Stand und Prüfhinweis: Dieser Beitrag wurde am 20.08.2026 aktualisiert. Die Aussagen zu Xcode 27, externem Agent-Zugriff, Coding Intelligence, Systemanforderungen und MDM wurden gegen die in diesem Beitrag verlinkten offiziellen Dokumente geprüft. Xcode 27 befindet sich weiterhin in einem Veröffentlichungszyklus, dessen Verhalten Sie vor jeder produktiven Freigabe erneut prüfen müssen.

SECTION 01 Die Vertrauensgrenze muss vor dem ersten Agent-Aufruf feststehen

Ein externer Agent kann über den von Apple beschriebenen Mechanismus Xcode Tools nutzen. Damit wird aus einer reinen Chat-Anfrage eine Verbindung zu Projektdateien, Xcode-Aktionen und möglicherweise ausführbaren Werkzeugen. Das bedeutet nicht automatisch, dass jeder Agent alles darf. Es bedeutet aber, dass Sie die Arbeitsumgebung wie einen technischen Operator mit klar begrenztem Zugriff behandeln müssen.

Die grundlegende Vertrauensgrenze sieht so aus:

Externer Agent
      │
      │ kontrollierter Tool- und Befehlszugriff
      ▼
Xcode-27-Testknoten ── isoliertes macOS-Konto ── isolierter Arbeitsbereich
      │
      ├── Quellcode-Checkout mit Projektfreigabe
      ├── Build- und Testwerkzeuge
      └── keine Produktionszertifikate, keine Release-Schlüssel
                                      │
                                      ▼
                         unabhängige Signatur- und Release-Pipeline

Die entscheidende Trennung liegt nicht zwischen „KI“ und „Nicht-KI“, sondern zwischen veränderbarem Quellcode, ausführbaren Aktionen und nicht ersetzbaren Vertrauensnachweisen. Ein Agent darf in einem Testbereich Dateien ändern und einen Build anstoßen. Er sollte jedoch nicht zugleich Zugriff auf Produktionsschlüssel, interne Administrationsnetze und den finalen Veröffentlichungsprozess erhalten.

Die Vertrauensgrenze sollte außerdem festlegen, welche Daten ein Modell überhaupt sehen darf. Quellcode, Build-Protokolle und Fehlermeldungen können unterschiedliche Schutzklassen besitzen. Ein Projekt mit internen Zugangsdaten, personenbezogenen Testdaten oder proprietären SDKs darf nicht einfach mit einem allgemeinen Pilotprojekt gleichbehandelt werden.

Ein externes Modell darf daher nicht allein deshalb als ungefährlich gelten, weil es „nur Code vorschlägt“. Sobald ein Tool Aufträge an Xcode weitergibt oder Änderungen in einem Arbeitsbereich ausführt, gelten dieselben Anforderungen wie bei jeder automatisierten Entwicklungsintegration.

SECTION 02 Welche Zugriffswege bringen die größten Risiken?

Projektzugriff und Identitätsvermischung

Ein häufiger Fehlaufbau verwendet das persönliche Administratorkonto eines Entwicklers, dessen vorhandener Checkout, SSH-Schlüssel, Keychain und lokale Konfiguration bereits auf mehrere Unternehmensdienste zugreifen. Der Agent erbt dann nicht nur die Projektdateien, sondern indirekt auch die Vertrauensbeziehungen dieses Kontos.

Für den Pilotbetrieb benötigen Sie deshalb ein dediziertes macOS-Konto. Dieses Konto sollte weder lokale Administrationsrechte besitzen noch als allgemeines Entwicklerkonto verwendet werden. Der Quellcode wird in eine separate Arbeitskopie ausgecheckt. Persönliche Home-Verzeichnisse, nicht benötigte Repositories und lokale Konfigurationsdateien gehören nicht auf diesen Knoten.

Wie kann ein externer AI Agent in Xcode auf ein Projekt zugreifen?
Sie aktivieren den von Apple dokumentierten externen Zugriff auf Xcode Tools nur auf einem freigegebenen Testknoten. Danach begrenzen Sie das zugängliche Projekt auf eine eigene Arbeitskopie und prüfen, welche Xcode-Funktionen der Agent tatsächlich ansprechen kann. Die Modellunterstützung, konkrete Einstellungen und das Verhalten der jeweiligen Xcode-27-Version dürfen Sie nicht aus Blogberichten ableiten, sondern müssen Sie in Ihrer installierten Version anhand der offiziellen Apple-Anleitung verifizieren.

Die Vertrauensbeziehungen sollten Sie in einer Matrix dokumentieren, nicht nur in einer Freitext-Richtlinie:

Diese Tabelle beantwortet nicht nur die Frage „Wer darf was?“. Sie zeigt auch, welche Verbindung Sie bei einem Vorfall zuerst trennen müssen. Wird etwa das Agent-Dienstkonto kompromittiert, darf der Vorfall nicht automatisch die Produktionssignatur betreffen.

Befehle und Werkzeuge

Kann ein Unternehmen die von Xcode AI Agent ausgeführten Befehle begrenzen?
Ja, die offiziellen Xcode-Dokumente beschreiben Einstellungen für Agent-Befehle und Tool-Berechtigungen. Diese Einstellungen sind jedoch nur eine Ebene. Sie müssen zusätzlich macOS-Kontorechte, Netzwerkregeln, Repository-Berechtigungen und die Verfügbarkeit sensibler Dateien begrenzen. Ein Model Context Protocol ist dabei lediglich ein Übertragungsweg für Fähigkeiten; es ist keine vollständige Autorisierungsschicht.

Die Freigabe sollte stufenweise erfolgen:

1. Nur lesen: Der Agent darf Projektstruktur, Build-Einstellungen und ausgewählte Protokolle prüfen.
2. Prüfen: Der Agent darf statische Prüfungen, Tests oder einen nicht signierenden Build anstoßen.
3. Begrenzt ändern: Änderungen sind nur in einer isolierten Arbeitskopie erlaubt.
4. Review erzwingen: Jede Änderung wird außerhalb der Agent-Sitzung geprüft und gegen den Ausgangsstand verglichen.
5. Produktionsgrenze beibehalten: Signatur, Veröffentlichung und Zugriff auf Release-Schlüssel bleiben außerhalb des Agent-Knotens.

Nicht notwendige Systemwerkzeuge sollten Sie nicht pauschal freischalten. Besonders kritisch sind Befehle, die Prozesse beenden, Netzwerkregeln ändern, neue Zugangsdaten installieren, Dateien außerhalb des Projektverzeichnisses durchsuchen oder administrative Einstellungen verändern. Die konkrete Liste muss aus Ihrem Buildsystem und dem Projektbedarf abgeleitet werden; eine universelle Zahl zulässiger Befehle wäre fachlich nicht belastbar.

Die Apple-Dokumentation zu Agent-Erweiterungen und Berechtigungen ist deshalb als Versionsreferenz wichtig. Sie beschreibt, welche Steuerungsmöglichkeiten Apple bereitstellt, aber nicht, welche Kombination für Ihre Organisation automatisch sicher ist.

Schlüsselbund, Zertifikate und interne Abhängigkeiten

Wie verhindert ein Unternehmen, dass Xcode AI Agent Signaturzertifikate und Produktionsschlüssel liest?
Die zuverlässigste Maßnahme besteht darin, den Agent-Arbeitsbereich gar nicht erst mit diesen Daten auszustatten. Ein Verbot in einer Anweisung genügt nicht, wenn das macOS-Konto oder ein Prozess über den Schlüsselbund auf dieselben Geheimnisse zugreifen kann.

Für die Infrastruktur sollten Sie mindestens drei Knotenklassen unterscheiden:

Die Trennung muss auch für interne Abhängigkeiten gelten. Wenn ein Testknoten uneingeschränkten Zugriff auf ein internes Paketregister, ein Unternehmens-VPN oder Deployment-Endpunkte besitzt, kann ein Agent über einen scheinbar harmlosen Build-Auftrag deutlich mehr Informationen erreichen als nur den Quellcode.

Apple stellt mit „Managing Files and Folders in Your Xcode Project“ die Grundlage für den Umgang mit Projektdateien bereit. Die unternehmensspezifische Sicherheitsentscheidung betrifft darüber hinaus die Verzeichnisstruktur: Legen Sie Geheimnisse nicht in Projektordner, Build-Skripte oder lokale Konfigurationsdateien, die der Agent für seine Aufgabe lesen muss.

Erfahrung aus der Architekturprüfung: Ein isoliertes Konto schützt nicht vor bereits eingebundenen Geheimnissen. Prüfen Sie deshalb vor der Aktivierung den Schlüsselbund, Umgebungsvariablen, SSH-Konfiguration, lokale Paketquellen und gespeicherte Sitzungen. Was der Prozess lesen kann, gilt als erreichbar, auch wenn es nicht ausdrücklich dokumentiert wurde.

SECTION 03 Wie wählen Sie die richtige Mac-Knotenstruktur?

Ein gemeinsamer Mac kann für harmlose, klar getrennte Aufgaben genügen. Er ist aber keine automatische Mehrmandantenplattform. Gemeinsame macOS-Konten, ein gemeinsames Quellcodeverzeichnis, dieselben DerivedData-Verzeichnisse und nicht bereinigte Caches schaffen mehrere Wege zur Kreuzkontamination.

Typische Fehlerpfade sind:

• Ein Agent findet Dateien eines vorherigen Projekts in einem wiederverwendeten Arbeitsverzeichnis.
• Build-Artefakte oder DerivedData enthalten Pfade, Namen oder Konfigurationswerte eines anderen Projekts.
• Ein Entwickler verwendet dieselbe Sitzung, während ein automatisierter Auftrag noch läuft.
• Ein Cache übernimmt Abhängigkeiten aus einer anderen Vertrauensstufe.
• Ein nicht beendeter Prozess hält Dateien, Ports oder temporäre Zugangsdaten offen.

Die Knotenplanung sollte daher nicht aus der beworbenen Chipleistung abgeleitet werden. Verwenden Sie stattdessen ein variables Kapazitätsmodell:

benötigte Knoten =
gleichzeitige Agent-Aufträge
× durchschnittliche Auftragsdauer
÷ verfügbare Arbeitszeit je Knoten
+ Sicherheitsreserve für Bereinigung und Wiederherstellung

Die Eingaben müssen Sie aus Ihren eigenen Build- und Agent-Protokollen gewinnen. Ohne Messwerte zu Auftragsdauer, Bereinigungszeit und Spitzenlast wäre eine konkrete Knotenanzahl eine Scheingenauigkeit.

Braucht ein entfernter Mac für Xcode AI Agent ein eigenes Konto?
Für einen belastbaren Unternehmenspilot sollten Sie diese Frage mit Ja beantworten. Ein dediziertes Konto macht die Verbindung zwischen Sitzung, Prozess, Arbeitsbereich und Audit-Log nachvollziehbar. Zusätzlich sollte der Zugang für Entwickler, Agent-Dienst und Fernverwaltung getrennt werden. Einen entfernten Mac lediglich über VNC mit einem persönlichen Administratorkonto zu bedienen, löst die Identitätsfrage nicht.

MDM kann bei Geräte- und Konfigurationsvorgaben helfen, ersetzt aber keine Agent-spezifische Projektfreigabe. Prüfen Sie die verfügbaren Einschränkungen in den offiziellen Apple-Platform-Deployment-Unterlagen. Für die Praxis müssen Sie unterscheiden, welche Einstellung das Gerät zentral verwaltet und welche Kontrolle nur in Xcode, im Betriebssystem oder in Ihrer CI/CD-Plattform umgesetzt werden kann.

Für Remote-Knoten sollten Sie außerdem die Zugangsebenen trennen:

• SSH für reproduzierbare Administration und nicht-interaktive Prüfungen;
• VNC oder Webkonsole nur für freigegebene interaktive Wartung;
• Agent-Zugriff über die dokumentierte Xcode-Schnittstelle;
• getrennte Protokollierung für Anmeldung, Agent-Auftrag, Befehl, Build und Rücksetzung.

Wenn Sie dafür zunächst Kapazität testen möchten, können Sie die verfügbaren Mac-Remote-Angebote von VPSNIX als Ausgangspunkt für einen isolierten Testknoten prüfen. Die tatsächliche Eignung muss anhand Ihres Projekts, Ihrer Netzwerkregeln und Ihrer Rücksetzprozedur bewertet werden; eine Produktseite ersetzt keinen Sicherheitsnachweis.

SECTION 04 Welche Nachweise entscheiden über die Freigabe?

Ein Agent-Pilot ist nicht erfolgreich, wenn lediglich ein Build durchläuft. Für die Freigabe müssen Sie zeigen, dass unerlaubte Zugriffe verhindert, erlaubte Änderungen nachvollzogen und fehlerhafte Zustände beseitigt werden können.

Fünf Prüfbereiche für die Abnahme

1. Verbindung: Der externe Agent erreicht nur die vorgesehene Xcode-Schnittstelle. Ein unerwarteter Zugriff auf Shell, fremde Projekte oder administrative Funktionen führt zum Abbruch des Piloten.
2. Projektgrenze: Der Agent kann nur die freigegebene Arbeitskopie lesen und ändern. Ein Vergleich des Dateisystems vor und nach dem Auftrag muss zusätzliche Änderungen sichtbar machen.
3. Befehlsgrenze: Jeder zugelassene Build- oder Testschritt ist dokumentiert. Nicht benötigte Werkzeuge bleiben deaktiviert oder werden durch Betriebssystem- und Netzwerkregeln blockiert.
4. Geheimnisgrenze: Der Testknoten enthält keine Produktions-Keychain, keine Release-Profile und keine dauerhaften Zugangsdaten. Testgeheimnisse müssen widerrufbar sein.
5. Wiederherstellung: Nach einem fehlgeschlagenen Auftrag können Sie den Arbeitsbereich verwerfen, den Knoten bereinigen und die Zugangsdaten sperren, ohne den Produktionsprozess zu gefährden.

Die Auditierung sollte mindestens folgende Nachweise verbinden:

Die offizielle Dokumentation zu Coding-Intelligence-Einstellungen sollte neben Ihren internen Kontrollen geprüft werden. Sie ist besonders relevant, wenn Sie die Nutzung zentral verwalten oder Einstellungen über MDM durchsetzen wollen. Da sich Xcode 27 noch im Veröffentlichungszyklus befindet, müssen Sie bei jeder Aktualisierung erneut prüfen, ob sich Namen, Verhalten oder Voraussetzungen geändert haben. Die Xcode-27-Beta-Release-Notes sind hierfür die maßgebliche Änderungsquelle.

Die Abnahmekriterien als Entscheidungsmatrix

Diese Matrix verhindert, dass ein erfolgreicher Demo-Build als Sicherheitsfreigabe missverstanden wird. Für die Produktion müssen Sie zusätzlich klären, ob der Prozess mit DSGVO-Anforderungen, internen Geheimschutzregeln, Aufbewahrungsfristen und den Vorgaben Ihres Codehostings vereinbar ist. Nicht jede externe Modellverarbeitung ist automatisch mit Ihren Datenverarbeitungsverträgen vereinbar; ungeklärte Datenflüsse bleiben ein Ablehnungsgrund.

SECTION 05 Ein umsetzbarer Prüfablauf für Ihren Pilotknoten

Die folgenden Schritte sind absichtlich auf die Problemfelder Zugriff, Identität, Geheimnisse, Verschmutzung und Auditierung ausgerichtet.

1. Projekt klassifizieren: Markieren Sie vor der Einrichtung, ob der Code interne Informationen, personenbezogene Daten, Geschäftsgeheimnisse oder release-relevante Logik enthält. Nicht klassifizierte Repositories werden nicht für den ersten Pilot geöffnet.

2. Apple-Silicon-Knoten reservieren: Verwenden Sie einen unabhängigen Mac, der nicht als täglicher Entwicklerarbeitsplatz und nicht als Produktionssignaturknoten dient. Prüfen Sie die zu Ihrer Xcode-27-Version passende offizielle Systemanforderung, bevor Sie das Image oder die Softwareinstallation standardisieren.

3. Konten und Fernzugriff trennen: Erstellen Sie ein dediziertes macOS-Konto für die Agent-Arbeitskopie. Legen Sie separate Zugänge für Fernadministration, Entwicklerzugriff und Automatisierung an; persönliche SSH-Schlüssel und lokale Entwicklerprofile werden nicht übernommen.

4. Arbeitskopie erzeugen: Checken Sie nur das freigegebene Repository aus. Entfernen Sie nicht benötigte Unterprojekte, lokale Konfigurationsdateien, alte Caches und gespeicherte Sitzungen. Legen Sie den Arbeitsbereich so an, dass er nach dem Auftrag vollständig gelöscht und neu erzeugt werden kann.

5. Netzwerk minimieren: Erlauben Sie nur Codehosting, Paketquellen, Build-Abhängigkeiten und die für den Test tatsächlich erforderlichen Dienste. Produktions-Deployment, interne Administrationsnetze und nicht benötigte Dateifreigaben bleiben gesperrt.

6. Xcode- und Agent-Rechte prüfen: Aktivieren Sie den externen Zugriff nach Apples Dokumentation. Beginnen Sie mit lesenden Prüfungen und nicht signierenden Builds. Protokollieren Sie jede freigegebene Aktion und vergleichen Sie die tatsächlich ausgeführten Werkzeuge mit der Richtlinie.

7. Geheimnisfreiheit verifizieren: Untersuchen Sie Keychain, Umgebungsvariablen, SSH-Agent, Paketmanager-Konfiguration und Build-Skripte. Führen Sie den Test nicht fort, wenn Produktionszertifikate, Provisioning Profiles oder dauerhafte Tokens erreichbar sind.

8. Parallelität kontrollieren: Starten Sie keine unabhängigen Agent-Aufträge im selben Arbeitsverzeichnis. Wenn mehrere Aufgaben erforderlich sind, verwenden Sie getrennte Arbeitskopien oder getrennte Knoten und definieren Sie, wann ein Knoten nach einem Auftrag zwingend zurückgesetzt wird.

9. Fehler absichtlich auslösen: Prüfen Sie einen verweigerten Befehl, einen abgebrochenen Build, eine ungültige Abhängigkeit und eine unterbrochene Remote-Sitzung. Entscheidend ist, ob Sie den Auftrag beenden, den Zustand sichern und den Knoten ohne Produktionsauswirkung wiederherstellen können.

10. Freigabe dokumentieren: Verknüpfen Sie Verbindungsdaten, Agent-Auftrag, Diff, Befehlsprotokoll, Build-Ausgabe und Entscheidung. Erst wenn diese Nachweise vollständig sind, entscheiden Sie zwischen weiterem Pilot, größerem Knotenpool oder Aussetzung.

Für den internen Kapazitätsplan sollten Sie die gemessene Zahl paralleler Aufträge, die durchschnittliche Laufzeit, Wartezeiten für Abhängigkeiten und die Dauer der Rücksetzung erfassen. Daraus lässt sich eine belastbare Knotenplanung ableiten. Chipbenchmarks oder Herstellerangaben beantworten dagegen nicht, wie viele isolierte Agent-Arbeitsbereiche Ihre Projekte im Alltag benötigen.

Eine weiterführende Betrachtung ist die Planung der Xcode-Cloud- und iOS-Buildserver-Architektur. Sie ist besonders hilfreich, wenn Sie den Agent-Pilot nicht als Ersatz für die Release-Pipeline, sondern als vorgelagerte Entwicklungs- und Prüfzone einordnen möchten.

SECTION 06 Wann ist ein Ausbau des Knotenpools vertretbar?

Erweitern Sie nicht nach dem ersten erfolgreichen Projekt. Eine Ausweitung ist erst sinnvoll, wenn der Pilot wiederholbar ist und die Fehlerfälle ebenso sauber behandelt werden wie der Normalfall. Dazu gehören eine dokumentierte Rücksetzung, widerrufbare Zugangsdaten, nachweisbare Befehlsgrenzen und ein klarer Prozess für ungewöhnliche Agent-Aktionen.

Die Aufteilung des Pools sollte nach zwei Achsen erfolgen:

• Vertrauensstufe: interne Entwicklungsprojekte, vertrauliche Projekte und release-nahe Projekte;
• Auftragstyp: Analyse, Test, nicht signierender Build und manuelle Review-Unterstützung.

Ein Knoten darf wiederverwendet werden, wenn die Projekte dieselbe Schutzklasse besitzen, der Arbeitsbereich vollständig neu erzeugt wird und keine Sitzung oder Zugangsdaten zurückbleiben. Ein eigener Knoten ist erforderlich, wenn ein Projekt besondere Geheimnisse, ein separates Netzwerk oder eine andere Aufbewahrungs- und Prüfpflicht besitzt.

Für eine belastbare Infrastrukturentscheidung können Sie die Anforderungen an gemeinsam genutzte Mac-Konten und Zugangsdaten anhand Ihrer internen Abnahmeliste prüfen. Bei Fernzugriffen sollten Sie außerdem die Datenschutz- und Verarbeitungsinformationen von VPSNIX mit Ihren eigenen DSGVO-Anforderungen abgleichen. Das ersetzt keine rechtliche Prüfung, hilft Ihnen aber, technische und organisatorische Fragen vor dem Einkauf zu sammeln.

Mietknoten oder eigener Mac?

Ein eigener Mac ist sinnvoll, wenn Sie dauerhaft hohe Auslastung, physische Schnittstellen, langfristige Hardwarekontrolle oder eine fest definierte interne Betriebsumgebung benötigen. Er verursacht jedoch Beschaffung, Abschreibung, Ersatzteilplanung, Administration und die Bereitstellung eines sicheren Standorts.

Ein gemieteter Remote-Mac ist für einen Pilot oder schwankende Nachfrage interessanter, weil Sie keinen eigenen Rechner pro Entwickler beschaffen müssen und die Kapazität zunächst anhand realer Agent-Aufträge testen können. Gegenüber dem Kauf bleiben aber Fragen zu Netzwerkpfad, Fernzugriff, Datenklassifizierung, Support und Rücksetzung offen; diese müssen Sie vor der Freigabe testen, nicht nur vertraglich annehmen.

Wenn Sie bereits einen eigenen Mac als dauerhaftes Buildsystem betreiben, ist ein Remote-Mietknoten nicht automatisch die bessere langfristige Lösung. Für einen isolierten Xcode-27-Pilot kann er jedoch die Beschaffung eines zusätzlichen Produktionsgeräts vermeiden, sofern der Knoten tatsächlich ohne Produktionsschlüssel geliefert, kontrolliert genutzt und nach jedem Test zuverlässig zurückgesetzt werden kann.

Der sinnvollste nächste Schritt ist daher kein allgemeiner Agent-Rollout, sondern ein begrenzter Test mit einem separaten Apple-Silicon-Mac: ein klassifiziertes Projekt, ein dediziertes Konto, keine Produktionssignatur und ein dokumentierter Rücksetztest. Wenn Verbindung, Befehlsgrenzen, Build und Audit funktionieren, kann VPSNIX als gemietete Remote-Mac-Option für die Kapazitätsbewertung dienen. Wenn Sie dagegen dauerhaft schwere Builds, physische Geräte oder eine vollständig eigene Netzwerk- und Schlüsselverwaltung benötigen, bleibt der selbst betriebene Mac die ehrlichere Wahl.

Weiterlesen

• Xcode Cloud oder eigener iOS-Buildserver: Welche Infrastruktur passt zu isolierten Unternehmens-Workflows?
• iOS-Signaturzertifikate sicher rotieren und in automatisierten Build-Prozessen verwalten