Als bevorzugte Quelle bei Google hinzufügen
Das Löschen deiner gesamten Produktionsdatenbank und der Backups ist nichts, was ein Mensch oft tun würde, aber für einen KI-Agenten, der nach strengen Anweisungen arbeitet, ist es möglich. Eine Nichtübereinstimmung der Anmeldedaten innerhalb des Codes wird von einem Agenten nicht überprüft.
Ohne Sicherheitsvorkehrungen macht er einfach weiter, ohne Rücksicht auf Verluste. Genau das ist PocketOS im April 2026 passiert, aber es war nicht die Schuld des KI-Agenten. Vielmehr zeigt es, dass die Infrastruktur und die Kontrolle rund um agentenbasierte Arbeitsabläufe menschliche Aufsicht erfordern.
In diesem Beitrag geht es darum, wie man solche agentenbasierten Sicherheitsvorkehrungen mithilfe der Funktionen von Kinsta einsetzt. Dabei spielen sowohl die Kinsta-API als auch das MyKinsta-Dashboard eine Rolle. Je mehr Aufgaben KI-Agenten übernehmen, desto strenger müssen die Kontrollen sein, bei denen ein Mensch destruktive Schritte genehmigen muss.
Warum der Zugriff auf die Produktionsumgebung ein Risiko für einen KI-Agenten darstellt
Wenn es um Fehler geht, versagen ein typisches Skript und ein KI-Agent auf unterschiedliche Weise. Bei einem Skript siehst du einen Fehler auf dem Bildschirm. Selbst wenn du auf einen „White Screen of Death“ stößt, ist das immer noch ein Fehler, der angezeigt wird. Das liegt daran, dass du in fast allen Fällen eine Fehlerbehandlung in ein Skript einbaust.
Der Natur der KI liegt es jedoch, eine Aufgabe zu erfüllen. Das bedeutet, dass ein KI-Agent zwar Erfolg melden kann, aber stillschweigende Fehler verursacht. Das passiert trotzdem, weil ein Modell dir zum Erfolg verhelfen will. Dies führt zu erfundenen oder synthetisierten Ergebnissen.
Bei WordPress ist ein Agent, der im Rahmen seiner Aufgaben Changelogs, API-Antworten, gescrapte Inhalte oder Ähnliches durchsucht, anfällig für Angriffe. Im April 2026 veröffentlichte Essential Plugin eine Hintertür, die bösartigen Code an über 400.000 Websites sendete, bevor sie geschlossen wurde. Das bietet jedoch keine Lösung für kompromittierte Websites.
Ein KI-Agent, der im Rahmen seines Workflows automatisch Plugin-Updates installiert, kann nicht zwischen legitimen und kompromittierten Updates unterscheiden. Sofern du keine Überprüfung in der Staging-Umgebung einbaust, kann dir diese Art von Angriff ebenfalls passieren. Der Bericht von Opsin Labs aus dem Jahr 2026 über den Einsatz von Agenten hebt hervor, dass 60 % der KI-Agenten über mehr Berechtigungen verfügen als nötig. Es handelt sich um dasselbe Berechtigungsproblem, das bei menschlichen WordPress-Teams auftritt und nun auch bei Agenten zutage tritt.
Wie Staging den Fehler eines KI-Agenten zu einem unbedeutenden Vorfall machen kann
Eine Staging-Prüfung als Teil deiner Workflow-Anweisungen gibt dir die Möglichkeit, bestimmte Aspekte der Agenten-Bereitstellung zu hinterfragen. Wenn beispielsweise ein Entwickler eine geplante Änderung pusht, weiß er genau, um welche Änderungen es sich handelt.
Im Gegensatz dazu versucht ein KI-Agent, der im Rahmen einer mehrstufigen Aufgabe Anweisungen abarbeitet, lediglich, die Aufgabe für dich zu erledigen. In Kombination mit der möglichen Informationssynthese bedeutet dies, dass ein Überprüfungs-Checkpoint unerlässlich ist.
Wenn du den Angriff auf die WordPress-Lieferkette mit einem Agenten vergleichst, der Updates auf Produktionsniveau vornimmt, nehmen beide Änderungen ohne Überprüfung vor. Kinsta bietet für alle Websites kostenlose Staging-Umgebungen an, um dieses Problem zu bekämpfen:
Du hast außerdem die Möglichkeit, Premium-Staging-Umgebungen zu nutzen, wenn du mit einer Spezifikation arbeiten musst, die näher an der Produktionsumgebung liegt.
Damit werden die von einem KI-Agenten vorgenommenen Änderungen erst dann aus dem Staging übertragen, wenn du dich entscheidest, die Umgebung live zu schalten:
Dies bietet dir detaillierte Optionen, um die Datenbank, Dateien oder beides zusammen zu übertragen. MyKinsta erstellt außerdem zuerst ein automatisches Backup der Zielumgebung. Die gleiche Logik gilt auch für die automatischen Updates von Kinsta.
Eine praktische Möglichkeit, die Staging-Umgebung in deinen Workflow einzubinden, besteht darin, die Produktionsumgebung in die Staging-Umgebung zu klonen, bevor du eine Agent-Aufgabe ausführst. Führe dann den KI-Agenten in der Staging-Umgebung aus und überprüfe das Ergebnis. Schließlich kannst du mit dem selektiven Push die Änderungen genehmigen und an die Produktionsumgebung senden.
Anwendung des Prinzips der geringsten Berechtigungen, bevor ein KI-Agent auf WordPress zugreift
Der Zugriff und die Berechtigungen von Agenten funktionieren nach denselben Prinzipien wie bei Menschen. Das Prinzip der geringsten Berechtigungen ist ein grundlegendes Sicherheitskonzept:
[QUOTE]Ein Agent oder Mensch sollte nur über das Mindestmaß an Berechtigungen und Zugriffsrechten verfügen, das er zur Ausführung einer Aufgabe benötigt – und nicht mehr.[/QUOTE]
Die bestehenden Rollen- und Berechtigungseinstellungen von Kinsta gelten sowohl für KI-Agenten als auch für Menschen:
- „Unternehmensadministrator“, der volle Kontrolle über dein gesamtes Kinsta-Konto gewährt. Kaum ein KI-Agent benötigt diese Rolle.
- Mit der Rolle„Unternehmensentwickler“ kann dein Agent alle deine Websites und dein DNS verwalten.
- Mit derRolle „Website-Administrator“ kannst du einem Agenten vollen Zugriff auf eine Website gewähren.
- DieRolle „Website-Entwickler“ eignet sich am besten für agentenbasierte Arbeitsabläufe, da sie nur Zugriff auf der Staging-Ebene gewährt.
Das Zuweisen von Rollen bedeutet auch, dass du deinen Agenten API-Schlüssel zuweisen musst. Ein Kinsta-API-Schlüssel übernimmt die Zugriffsebene der Rolle, die ihn generiert. Das ist eine gute Möglichkeit, den Zugriff eines KI-Agenten automatisch einzuschränken.
Ein solider, sicherer Workflow besteht darin, API-Schlüssel pro Agent oder pro Workflow zu generieren. Das machst du über den Bildschirm „Unternehmenseinstellungen > API-Schlüssel“ in MyKinsta:
Durch das Festlegen einer Ablaufzeit hast du die Möglichkeit, die Zugriffsrechte zu überprüfen. Wenn sich dein Workflow ändert, hast du nun eine naheliegende Möglichkeit, deine Zugriffsrechte und Berechtigungen neu zu bewerten.
Warum Backups ein wichtiger Bestandteil deines automatisierten Workflows sein sollten
Da sich die Ursachen für Fehler bei menschlichen und agentischen Arbeitsabläufen unterscheiden, gilt dies auch für den Bedarf an Backups. Zum Beispiel ist eine Pause durch einen Menschen ganz natürlich, wenn er eine destruktive Aufgabe ausführt. Da ein KI-Agent jedoch Anweisungen befolgen muss, wird er nicht innehalten, um nachzudenken oder etwas noch einmal zu überprüfen. Die Lösung besteht darin, eine feste Vorgabe einzubauen.
Das bedeutet, dass ein Backup nur dann ein Sicherheitsnetz ist, wenn es außerhalb dessen liegt, was es löschen könnte. Der PocketOS-Vorfall ist zum Beispiel ebenso sehr ein architektonisches Problem im Zusammenhang mit Backups wie ein Berechtigungsproblem. Das Speichern von Backups auf Volume-Ebene auf dem Volume selbst lässt sich per Code beheben.
Allerdings ist es bei Kinsta nicht möglich, nur ein altes Backup zur Wiederherstellung deiner Datenbank zur Verfügung zu haben:
- Tägliche automatische Backups bieten dir eine Basis, unabhängig davon, was ein Agent tut.
- Vom System generierte Backups werden vor einem selektiven Push oder Update ausgeführt, selbst wenn sie von einem Agenten ausgelöst werden.
- Mit manuellen Backups kannst du bei Bedarf deine eigenen Wiederherstellungspunkte (mit Tags) erstellen.
Mit der Kinsta-API kannst du Prüfungen einbauen, bevor ein KI-Agent einen destruktiven Schritt ausführt:
const KINSTA_API_URL = 'https://api.kinsta.com/v2';
const headers = {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.KINSTA_API_KEY}`
};
const createBackup = async (envId, tag) => {
const resp = await fetch(`${KINSTA_API_URL}/sites/environments/${envId}/manual-backups`, {
method: 'POST',
headers,
body: JSON.stringify({ tag })
});
return resp.json();
};
const pollOperation = async (operationId, intervalMs = 5000, maxAttempts = 12) => {
for (let i = 0; i < maxAttempts; i ) {
const resp = await fetch(`${KINSTA_API_URL}/operations/${operationId}`, { method: 'GET', headers });
const data = await resp.json();
if (data.status === 200) return data;
if (data.status >= 400) throw new Error(`Operation failed: ${data.message}`);
await new Promise(r => setTimeout(r, intervalMs));
}
throw new Error('Operation timed out');
};
const findBackupByTag = async (envId, tag) => {
const resp = await fetch(`${KINSTA_API_URL}/sites/environments/${envId}/backups`, { method: 'GET', headers });
const data = await resp.json();
return data.environment.backups.find(b => b.note === tag) || null;
};
const runAgentTask = async (envId, agentTask) => {
const tag = `pre-agent-action-${Date.now()}`;
const backup = await createBackup(envId, tag);
if (!backup.operation_id) throw new Error(`Backup request failed: ${JSON.stringify(backup)}`);
await pollOperation(backup.operation_id);
const verified = await findBackupByTag(envId, tag);
if (!verified) throw new Error('Backup not found after completion');
return agentTask();
};
Hier sendest du eine „ POST “-Anfrage, um ein manuelles Backup für eine Umgebung zu erstellen. Anschließend kann der Agent die Operations-ID abfragen und das Backup bestätigen. Nach der Bestätigung kann der Agent mit dem destruktiven Schritt fortfahren. Das Einbauen eines Schritts zur Erstellung eines Backups bei Änderungen an der Produktionsumgebung ist genauso wichtig und unverzichtbar wie jede andere Sicherheitseinstellung.
So überprüfst du den Umfang des KI-Agenten-Workflows in MyKinsta
Mithilfe der Informationen in MyKinsta kannst du prüfen, auf welche Bereiche deine Agenten Zugriff haben. Die programmatische Option über die Kinsta-API funktioniert nahezu sofort, wenn du sie in deine Anweisungen einbaust. Die MyKinsta-Oberfläche bietet dir jedoch die Möglichkeit, eine zehnminütige, manuell durchgeführte Überprüfung durchzuführen.
Stelle sicher, dass „Staging“ dein Standardpfad ist
Durch Stichproben im Vorfeld kannst du einige wichtige Informationen mit eigenen Augen überprüfen. Es gibt zwei Bereiche, die du überprüfen solltest:
- Instanzen von Produktionsumgebungs-IDs.
- Die automatischen Updates von Kinsta laufen an den richtigen Stellen in deinem Workflow ab.
Um deine Produktions- und Staging-IDs über MyKinsta zu finden, öffne das Dashboard einer Website und schau dir die URL an:
https://my.kinsta.com/sites/details/{site_id}/{environment_id}?idCompany={company_id}
Nutze das Dropdown-Menü „Umgebung“, um zwischen den Umgebungen zu wechseln, die du überprüfen möchtest. Öffne anschließend eine beliebige Konfigurationsdatei oder ein Skript, das deine Automatisierung steuert, und suche nach der Umgebungs-ID. Falls Produktions-IDs angezeigt werden, ersetze diese durch deine Staging-ID.
Um deine Einstellungen für die automatischen Updates zu überprüfen, navigiere zum Bildschirm „Plugins und Themes “. Klicke hier neben dem Abschnitt „Automatische Updates “ auf „Ändern “:
Mit der Lösung von Kinsta kannst du visuelle Regressionstests und Rollbacks nutzen, wenn du einen Fehler findest. Wenn sich die Vorher-Nachher-Screenshots der Seiten deiner Website unterscheiden, führt Kinsta ein Rollback auf eine „bekannte“ Version durch. Du kannst die Empfindlichkeit der visuellen Regressionstests anpassen und auch mit dynamischen Inhalten arbeiten.
Überprüfe, wer Zugriff auf deine API-Schlüssel hat
Eine einfache Überprüfung besteht darin, deine API-Schlüssel zu kontrollieren. Je nach Größe deines Teams und den Projekten, die du betreibst, gibt es möglicherweise viele abgelaufene oder anderweitig überflüssige Schlüssel, die du löschen solltest.
Gehe dazu in MyKinsta zu „Unternehmenseinstellungen“ > „API-Schlüssel “. Die Liste im Dashboard gibt keinen Aufschluss über die Zugriffsebene der einzelnen Schlüssel. Daher ist es unerlässlich, klare Namenskonventionen und Aufzeichnungen zu haben.
Du solltest drei Punkte überprüfen:
- Unter welcher Rolle ein Schlüssel generiert wurde.
- Das Ablaufdatum, das in der Liste angezeigt wird.
- Ob der Schlüssel noch für einen aktiven Workflow verwendet wird.
Bei jedem API-Schlüssel, der nicht aktiv ist, dessen Ablaufdatum aber noch nicht erreicht ist, kannst du auf die Schaltfläche „Widerrufen“ klicken, um ihn zu entfernen. Bei abgelaufenen Schlüsseln heißt die Schaltfläche „Löschen“. Die Aktion ist in beiden Fällen dieselbe.
Du kannst den Bildschirm „Benutzeraktivität“ in MyKinsta filtern, um zugehörige Aktivitäten anzuzeigen, bei denen ein bestimmter API-Schlüssel verwendet wird:
Für die programmgesteuerte Überprüfung gibt es Endpunkte zum Abrufen der Aktivitätsprotokolle und API-Schlüssel für ein Unternehmen.
Um jedoch die Informationen zur Zugriffsebene eines API-Schlüssels anzuzeigen, muss mindestens eine Aktion damit durchgeführt worden sein. Wenn ein Schlüssel also noch nie verwendet wurde, kannst du ihn bedenkenlos löschen.
Überprüfe, ob agentische Workflows einen Wiederherstellungspunkt haben
Öffne für deine Backups eine Site und schau dir den Reiter „Manuell“ unter „Backups“ an:
Achte hier auf fehlende oder falsche Notizen. Überlege dann, ob ein agentischer Workflow die API aufruft und ein manuelles Backup erstellt. Wenn ja, überprüfe unbedingt den Betriebsstatus, bevor der Agent ein Backup durchführt.
Außerdem kann es vorkommen, dass ein Agent mehr Backups auslöst, als du erwartest. Wenn deine fünf Slots für manuelle Backups voll sind, schau dir das Erstellungsdatum an. Das hilft dir bei der Entscheidung, ob du einen verschwenderischen Backup-Prozess optimieren musst.
Nutze das Aktivitätsprotokoll, um nach unzulässigen Aktionen zu suchen
Zurück auf dem Bildschirm „Benutzeraktivitäten“ solltest du sicherstellen, dass jede Aktion auf einen namentlich genannten Benutzer oder einen API-Schlüssel zurückgeführt werden kann. Du kannst ein Aktivitätsprotokoll auf Unternehmens- oder Website-Ebene einsehen.
Wenn du einen Eintrag abfragen möchtest, klicke darauf und nutze die Schaltfläche „Support anfragen “. So kannst du dem Support eine Nachricht senden und um weitere Details zur Art eines Eintrags bitten.
Es gibt auch eine programmatische Möglichkeit, auf Details zu Benutzeraktivitäten zuzugreifen, was dir eine weitere Option bietet, Überprüfungen in deinen Workflow zu integrieren. Menschliche Überprüfungen können hier jedoch Probleme aufdecken, die einem KI-Agenten möglicherweise entgehen.
Sicherheitsvorkehrungen machen den Einsatz von KI-Autonomie sicher
Die Funktionen von MyKinsta sind nicht speziell auf KI-Sicherheit ausgerichtet. Staging, Protokolle der Benutzeraktivitäten, automatisierte Backups und Berechtigungen verhindern, dass agentengesteuerte Workflows katastrophale Probleme verursachen. Du kannst den Workflow zudem in jedem Schritt steuern – entweder über das MyKinsta-Dashboard oder die Kinsta-API.
Um deine KI-Agenten vertrauenswürdiger zu machen, musst du ihnen den richtigen Handlungsspielraum geben und Sicherheitsvorkehrungen in den Prozess einbauen. Menschliches Eingreifen ist auch bei den am stärksten automatisierten Abläufen nach wie vor notwendig.
Wenn du dich für das leistungsstarke WordPress-Hosting von Kinsta entscheidest, erhältst du die Tools, um einen sicheren und geschützten agentenbasierten Zugriff zu gewährleisten. Für Agenturen bietet Kinsta die gleiche erstklassige Sicherheit und den gleichen erstklassigen Support für deinen gesamten Kundenstamm.
