Black Hat USA 2026: AI-Agent-Sicherheit auf Remote-Macs

Ein Coding Agent liest ein Token aus dem Arbeitsverzeichnis, nutzt es für ein privates Repository und schreibt den Build-Log anschließend an einen externen Dienst.

Die schnellste Lösung: Lassen Sie einen AI Agent auf einem Remote-Mac nur passieren, wenn Identität, Rechte, Geheimnisse, Netzwerk, Protokolle und Löschung getrennt nachweisbar kontrolliert werden. Antivirus und eingeschränkte Anmeldung reichen nicht.

Wer diese Prüfung braucht:
Diese Checkliste richtet sich an Teams, die Coding Agents auf private Repositories zugreifen lassen.
Sie ist ebenso für DevOps-Verantwortliche mit Signatur- oder Automatisierungsaufgaben sowie für Sicherheits- und Compliance-Leiter gedacht.

Letzte Aktualisierung: 29.07.2026. Die Veranstaltungsdaten wurden mit dem offiziellen Black-Hat-USA-2026-Programm abgeglichen. Black Hat USA 2026 ist vom 01.08.2026 bis 06.08.2026 in Las Vegas angesetzt; das offizielle Programm nennt unter anderem AI Summit, AI Zone und Arsenal. Offizieller Zeitplan und Veranstaltungsübersicht sowie offizielle Informationen zur AI Zone.

1. Risikokette vor der Freigabe

Der typische Fehler beginnt nicht mit einer spektakulären Schadsoftware. Er beginnt mit einer bequemen Konfiguration:

1. Der Agent läuft unter demselben Benutzerkonto wie ein Entwickler.
2. Das Konto besitzt Administratorrechte oder Zugriff auf den Standard-Schlüsselbund.
3. Ein persönliches Repository-Token liegt als Umgebungsvariable oder in einer Konfigurationsdatei.
4. Der Agent erhält einen Shell-Befehl, der nicht nur den Build, sondern auch Dateisuche und Netzwerkzugriff erlaubt.
5. Der Build-Log enthält den vollständigen Pfad, Umgebungsvariablen oder Fehlermeldungen mit geheimen Werten.
6. Nach dem Auftrag bleiben Cache, Sitzungsdaten, temporäre Dateien und geladene Schlüssel auf dem Remote-Mac zurück.

Jeder einzelne Schritt kann für sich plausibel wirken. Die Kombination erzeugt jedoch eine nicht mehr sauber zuordenbare Zugriffskette. Sie wissen dann nicht sicher, ob der Benutzer, der Agent, ein MCP-Server oder ein nachgelagerter Dienst eine Datei gelesen, verändert oder übertragen hat.

Das ist der Kern der Black Hat USA 2026 AI-Agent-Sicherheit: Autonome Werkzeuge müssen nicht nur gegen Schadcode geschützt werden. Ihre Identität und ihr Handlungsspielraum müssen so begrenzt sein, dass ein Fehlverhalten sichtbar bleibt und beendet werden kann. Die aktuellen Sicherheitsleitlinien für agentische Systeme behandeln unter anderem Tool-Missbrauch, Identitäts- und Rechteausweitung sowie unerwartete Codeausführung als eigene Risikoklassen. OWASP-Leitfaden zu Risiken agentischer Anwendungen

2. Identität und Verantwortlichkeit

Eigenständige Service-Identität

Der Agent sollte niemals mit dem persönlichen Konto eines Entwicklers arbeiten. Prüfen Sie:

• Gibt es ein eigenes Agent-Konto oder eine eindeutig benannte Service-Identität?
• Sind menschliche und automatisierte Aktionen im Repository getrennt erkennbar?
• Wird jede Aufgabe mit Auftraggeber, Agent-Version, Repository, Commit und Zeitstempel verknüpft?
• Können Sie die Identität nach Ende eines Auftrags sofort sperren?

Ein gemeinsames Administratorkonto ist direkt durchgefallen. Dasselbe gilt für ein langfristiges persönliches Zugriffstoken. Beide Varianten verhindern eine belastbare Verantwortungszuordnung. Bei einem Vorfall bleibt nur die Frage, welcher Mensch theoretisch Zugriff hatte. Das ist keine ausreichende Audit-Spur.

Für Repository-Zugriffe sollte die Identität möglichst auf ein Projekt, eine Umgebung und eine konkrete Aktion begrenzt sein. Ein Agent, der lesen und testen soll, benötigt normalerweise keine Rechte zum Löschen von Branches, Verwalten von Organisationsmitgliedern oder Ändern von Sicherheitsrichtlinien.

Nachweis der Trennung

Verlangen Sie als Beleg:

• Konfiguration der Service-Identität.
• Rechteübersicht des Repositorys.
• Beispiel eines erfolgreichen Agent-Auftrags.
• Beispiel eines abgewiesenen Schreib- oder Administrationsversuchs.
• Audit-Log mit menschlichem Auftraggeber und automatisierter Aktion.

Der Abnahmetest ist einfach: Starten Sie eine Aufgabe, die der Agent nicht ausführen darf. Wenn kein eindeutiger Ablehnungsgrund und kein Logeintrag entstehen, ist die Trennung nicht nachgewiesen.

3. Geheimnisse und Signaturmaterial

Fundstellen systematisch prüfen

Ein Agent kann Geheimnisse nicht nur aus Umgebungsvariablen lesen. Prüfen Sie mindestens:

• Shell-Historie und lokale Verlaufdateien.
• Arbeitsverzeichnisse und Build-Skripte.
• CI/CD-Konfigurationsdateien.
• Cache-Verzeichnisse von Paketmanagern.
• Protokolle des Agents und der MCP-Server.
• Standard-Schlüsselbund sowie benutzerdefinierte Schlüsselbunde.
• Temporäre Archive, Crash-Berichte und Debug-Ausgaben.

Der macOS-Schlüsselbund ist für Passwörter, Schlüssel, Zertifikate und andere vertrauliche Daten vorgesehen. Seine Existenz bedeutet jedoch nicht, dass jeder Prozess automatisch keinen Zugriff erhält. Zugriffsgruppen, Berechtigungen und der Ausführungskontext müssen separat geprüft werden. Technische Dokumentation zu Keychain Services

Kurzlebige Berechtigungen

Für Signaturzertifikate und API-Zugangsdaten gilt:

• Erst unmittelbar vor dem Auftrag bereitstellen.
• Nur für das konkrete Repository oder den konkreten Build freigeben.
• Nicht in das Git-Arbeitsverzeichnis kopieren.
• Nicht als Klartext in Shell-Befehlen übergeben.
• Nach dem Auftrag widerrufen oder löschen.
• Widerruf und Löschung im Audit-Log dokumentieren.

Bei einem Signaturprozess ist der private Schlüssel besonders kritisch. Ein sichtbares Zertifikat im Log ist bereits ein Datenschutz- und Vertrauensproblem; ein exportierbarer privater Schlüssel kann jedoch die Integrität Ihrer Releases gefährden. Für macOS-Software gehören Signatur, sichere Zeitstempel und ein kontrollierter Verteilungsprozess zusammen. Leitfaden zur Notarisierung von macOS-Software

Verwenden Sie bei automatisierten Abläufen möglichst einen separaten Signaturpfad. Der Agent darf den Build ausführen, aber nicht frei Schlüsselbundabfragen, Zertifikatexporte oder Änderungen an Signaturberechtigungen starten.

4. Werkzeuge und Systemrechte

Ein Agent ist nicht nur ein Chatfenster. Er kann Shell-Befehle, Skripte, Dateisystemoperationen, Paketmanager, Build-Werkzeuge und externe Dienste aufrufen. Deshalb muss die Tool-Liste als Sicherheitsgrenze behandelt werden.

Erlaubte und verbotene Aktionen

Ordnen Sie jeden Befehl einer von drei Gruppen zu:

• Erlaubt: Lesen definierter Quelldateien, lokaler Build, Tests im Arbeitsverzeichnis.
• Bedingt erlaubt: Paketinstallation, Änderung von Build-Konfigurationen, Erstellung von Artefakten.
• Verboten oder menschlich freizugeben: sudo, Systemkonfiguration, Schlüsselbundexport, Zertifikatexport, Löschen außerhalb des Arbeitsverzeichnisses, Änderung von Firewall-Regeln und unkontrollierte Netzwerkwerkzeuge.

Die Standardeinstellung muss „verweigern“ sein. Ein Agent darf nicht erst beweisen müssen, dass ein weitreichender Befehl gefährlich ist. Sie müssen nachweisen, warum ein Befehl benötigt wird.

Besonders wichtig ist die Trennung zwischen Dateirechten und Systemrechten. Ein Agent ohne Administratorrechte kann trotzdem sensible Daten lesen, wenn diese im Benutzerverzeichnis, in Logs oder in einer offenen Sitzung liegen. Umgekehrt kann ein normaler Build scheitern, wenn Sie den Agent zu stark beschneiden. Die richtige Lösung ist daher kein pauschales „alles sperren“, sondern ein enges Arbeitsverzeichnis mit expliziten Ausnahmen.

Menschliche Freigabe

Für jede privilegierte Aktion müssen mindestens folgende Daten gespeichert werden:

• Wer hat freigegeben?
• Welche konkrete Aktion wurde erlaubt?
• Für welches Ziel und welchen Zeitraum?
• Welche Begründung lag vor?
• Welches Ergebnis entstand?

Ein Chatverlauf allein reicht nicht, wenn er nicht manipulationsgeschützt gespeichert und mit der technischen Aktion verknüpft wird.

5. Vergleich der Betriebsmodelle

Die folgende Tabelle hilft bei der Vorauswahl. Sie ersetzt keinen technischen Test, zeigt aber, wo die größten Abnahmerisiken liegen.

Die letzte Zeile ist nicht automatisch die beste Wahl für jedes Team. Langfristige, schwere Builds oder Aufgaben mit physischen Schnittstellen können eine dauerhafte Maschine benötigen. Für Signaturaufgaben, private Quellcodes und automatisierte Releases ist eine schnell wiederherstellbare Umgebung jedoch meist leichter zu prüfen als ein über Jahre gewachsenes gemeinsames System.

Wenn Sie für die Auswahl und den Betrieb eines Remote-Mac zunächst die Anbieter- und Supportstruktur prüfen möchten, finden Sie die grundlegenden Informationen auf der VPSSpark-Übersichtsseite. Für die Sicherheitsabnahme sollten Sie trotzdem Ihre eigenen Identitäts-, Netzwerk- und Löschtests durchführen.

6. Netzwerk und Datenabfluss

Ein Agent braucht häufig Netzwerkzugriff. Das ist kein Argument für uneingeschränkten Internetzugang.

Erstellen Sie vor dem Start eine Positivliste für:

• Freigegebene Modell-Endpunkte.
• Private Code-Repositories.
• Paket- und Abhängigkeitsquellen.
• Signatur- und Notarisierungsdienste.
• Interne Protokoll- oder Artefaktspeicher.
• Zeit- und Identitätsdienste, sofern erforderlich.

Alle anderen Ziele müssen blockiert oder mindestens protokolliert und genehmigungspflichtig sein. Prüfen Sie nicht nur DNS- und Firewall-Regeln. Ein Agent kann Daten auch über Paketmanager, Webhooks, Fehlertelemetrie, eingebettete Bilder, Git-Remote-URLs oder einen MCP-Server übertragen.

Die offiziellen MCP-Sicherheitsempfehlungen behandeln unter anderem die Verifizierung eingehender Anfragen und den sicheren Umgang mit Sitzungen. Für Ihre Abnahme bedeutet das: Ein MCP-Server darf nicht als vertrauenswürdiger lokaler Prozess behandelt werden, nur weil er auf demselben Mac läuft. Offizielle MCP-Sicherheitsleitlinien

Exfiltrationstest

Führen Sie einen kontrollierten Test mit einem eindeutig markierten, nicht produktiven Testgeheimnis durch. Prüfen Sie:

1. Ob der Agent es im Arbeitsverzeichnis findet.
2. Ob es in einem Log oder Prompt erscheint.
3. Ob ein Tool versucht, es an ein nicht freigegebenes Ziel zu senden.
4. Ob die Firewall oder der Proxy den Versuch blockiert.
5. Ob der Block im Sicherheitsprotokoll erscheint.
6. Ob das Testgeheimnis nach dem Auftrag entfernt wird.

Verwenden Sie dafür niemals ein echtes Produktionszertifikat oder einen aktiven API-Schlüssel.

7. Protokollierung und Beweiskette

Ein brauchbares Protokoll muss eine komplette Aufgabe rekonstruieren können. Dafür benötigen Sie nicht zwingend jeden Textbestandteil des Prompts. Sie benötigen aber die sicherheitsrelevanten Ereignisse:

• Benutzer- und Service-Identität.
• Start- und Endzeit.
• Agent-Version und verwendete Tools.
• Zielpfad, Repository und Commit.
• Ausgeführter Befehl oder normalisierte Befehlsklasse.
• Ergebniscode und Fehlermeldung.
• Netzwerkziel und Übertragungsentscheidung.
• Menschliche Freigaben.
• Lösch- und Widerrufsstatus.

Protokolle dürfen nicht selbst zum Datenleck werden. Maskieren Sie Tokens, Passwörter, private Schlüssel, vollständige Quellcodeinhalte und personenbezogene Geschäftsdaten. Ein Log mit vollständiger Befehlszeile ist wertlos, wenn diese Befehlszeile ein Geheimnis als Parameter enthält.

Prüfen Sie die Protokollqualität mit einer einzigen Frage: Können zwei Personen, die nicht am Auftrag beteiligt waren, den Ablauf später nachvollziehen? Wenn nicht, fehlt entweder die Ereigniskette oder die Zuordnung zwischen Agent, Tool und Systemaktion.

8. Umgebung und Löschung

Eine Remote-Mac-Umgebung ist nach dem Logout nicht automatisch sauber. Prüfen Sie deshalb die folgenden Rückstände:

• Git-Arbeitsverzeichnis und nicht versionierte Dateien.
• Paketmanager- und Build-Caches.
• Agent-Sitzungen und Kontextspeicher.
• Shell-Historien.
• Temporäre Archive und Diagnoseberichte.
• Geladene Zertifikate und private Schlüssel.
• SSH-Agent- oder ähnliche Sitzungen.
• Lokale Logs und Exportdateien.
• Berechtigungen, die während des Auftrags erweitert wurden.

Die wichtigste Frage lautet nicht „Wurde die Datei gelöscht?“, sondern „Kann sie wiederhergestellt oder aus einem Cache rekonstruiert werden?“ Bei sensiblen Aufträgen sollte der Prozess eine neue, reproduzierbare Umgebung erzeugen und die alte Umgebung anschließend vollständig aus dem Betriebsbestand entfernen.

Ein einfacher Test besteht aus vier Durchläufen:

1. Testauftrag mit markierten Dateien und Testgeheimnissen ausführen.
2. Umgebung nach dem Auftrag herunterfahren oder zurücksetzen.
3. Nach Dateien, Prozessen, Schlüsselbundobjekten und Sitzungen suchen.
4. Neue Aufgabe starten und prüfen, ob keinerlei Kontext des vorherigen Auftrags sichtbar ist.

Wenn Sie nur Benutzerdateien löschen, aber ein langlebiges Maschinenabbild oder einen gemeinsam genutzten Cache behalten, ist die Isolation nicht vollständig.

9. Abnahme mit Punktesystem

Bewerten Sie jeden Bereich mit null, einem oder zwei Punkten:

• 0 Punkte: kein Nachweis oder direkter Verstoß.
• 1 Punkt: teilweise umgesetzt, aber mit dokumentierter Restlücke.
• 2 Punkte: technisch getestet, protokolliert und widerrufbar.

Prüfen Sie anschließend, ob mindestens alle kritischen Bereiche bestanden sind. Ein hoher Durchschnittswert darf keinen Blocker ausgleichen. Ein nicht widerrufbarer langfristiger Schlüssel bleibt ein Blocker, auch wenn Netzwerk und Protokollierung gut umgesetzt sind.

Abnahme-Checkliste

• [ ] Der Agent verwendet eine eigene Service-Identität.
• [ ] Persönliche Tokens und gemeinsame Administratorkonten sind ausgeschlossen.
• [ ] Benutzeraktionen und Agent-Aktionen erscheinen getrennt im Audit-Log.
• [ ] Repository-Rechte sind auf die erforderlichen Projekte und Aktionen begrenzt.
• [ ] Der Agent läuft ohne lokale Administratorrechte.
• [ ] Hochrisikobefehle benötigen eine menschliche Freigabe.
• [ ] Arbeitsverzeichnisse und erlaubte Dateipfade sind festgelegt.
• [ ] Geheimnisse liegen nicht in Shell-Historie, Logs oder Projektdateien.
• [ ] Signaturmaterial ist temporär und sofort widerrufbar.
• [ ] Der Zugriff auf den Schlüsselbund wurde mit einem Negativtest geprüft.
• [ ] Modell-Endpunkte, Repositorys und Abhängigkeitsquellen sind als Positivliste definiert.
• [ ] Unbekannte Netzwerkziele werden blockiert oder sichtbar protokolliert.
• [ ] Prompts, Quellcode, Artefakte und Logs werden nicht unkontrolliert weitergeleitet.
• [ ] Eine vollständige Agent-Aufgabe lässt sich nachträglich rekonstruieren.
• [ ] Tokens und sensible Geschäftsdaten werden in Logs maskiert.
• [ ] Cache, Sitzungen, temporäre Dateien und Credentials werden nach der Aufgabe entfernt.
• [ ] Eine neue Aufgabe startet ohne Kontext oder Rückstände des vorherigen Auftrags.

10. Freigabeentscheidung und nächste Aktion

Verwenden Sie drei klare Ergebnisse:

Bestanden: Alle kritischen Kontrollen sind getestet. Restrisiken sind dokumentiert und akzeptiert.

Nachbesserung mit Frist: Die Architektur ist grundsätzlich geeignet, aber ein nicht kritischer Nachweis fehlt. Legen Sie Verantwortlichen, Frist und erneuten Test fest.

Gesperrt: Der Agent darf nicht produktiv eingesetzt werden. Das gilt insbesondere bei nicht widerrufbaren Dauer-Credentials, unsichtbaren Hochrisikoaktionen, gemeinsamem Administratorkonto oder nicht kontrollierbaren externen Verbindungen.

Für die Planung rund um Black Hat USA 2026 sollten Sie die Checkliste vor dem offiziellen Veranstaltungszeitraum am 01.08.2026 intern anwenden und während der Briefings, Arsenal-Demos und AI-Zone-Inhalte nur solche neuen Erkenntnisse ergänzen, die offiziell veröffentlicht und technisch überprüfbar sind. Die Veranstaltung ist laut offizieller Planung bis zum 06.08.2026 angesetzt; nicht veröffentlichte Forschung darf vorab nicht als bestätigtes Ergebnis dargestellt werden.

Ein gemeinsam genutzter Remote-Mac mit dauerhaftem Benutzerkonto bleibt gegenüber diesem Modell im Nachteil: Verantwortlichkeiten vermischen sich, Schlüssel und Caches bleiben leichter zurück, und Netzwerk- oder Tool-Aktionen sind schwieriger einer einzelnen Aufgabe zuzuordnen. Für kurzfristige Tests, reproduzierbare Builds oder zeitlich begrenzte Agent-Aufgaben kann die Miete eines isolierten Macs von VPSSpark deshalb die sauberere operative Lösung sein — vorausgesetzt, Sie verlangen auch dort eigene Identitäten, kontrollierte Zugriffe, nachvollziehbare Logs und eine bestätigte Rückgabe beziehungsweise Löschung der Umgebung. Für eine konkrete Region können Sie anschließend die passende Remote-Mac-Option für die Vereinigten Staaten prüfen.

Die entscheidende Abnahme erfolgt nicht durch das Betriebssystem allein. Sie erfolgt durch den Nachweis, dass der Agent nur das tun kann, was Sie erlaubt haben, dass jede Ausnahme sichtbar bleibt und dass die Umgebung nach dem Auftrag keinen verwertbaren Rest zurücklässt.