Toevoegen als voorkeursbron op Google
Je hele productiedatabase en backups wissen doet een mens niet snel, maar een AI-agent die strikte instructies volgt, kan het wel. Een verschil in inloggegevens binnen de codebase is iets wat een agent niet zal controleren.
Zonder veiligheidsmaatregelen gaat hij simpelweg door. Dat gebeurde in april 2026 bij PocketOS, maar de schuld lag niet bij de AI-agent. Het laat juist zien dat de infrastructuur en controle rond agentic workflows menselijk toezicht nodig hebben.
In dit artikel kijken we hoe je die veiligheidsmaatregelen voor agents inzet met de functionaliteit van Kinsta. Zowel de Kinsta API als het MyKinsta dashboard spelen daarbij een rol. Naarmate AI-agents meer werk overnemen, zijn er strenge controles nodig waarbij een mens destructieve stappen goedkeurt.
Waarom toegang tot de productieomgeving een risico is voor een AI-agent
Een standaardscript en een AI-agent gaan op verschillende manieren de mist in. Bij een script zie je een foutmelding op het scherm. Zelfs een White Screen of Death is nog steeds een fout die je ziet. In vrijwel alle gevallen bouw je namelijk foutafhandeling in een script in.
Het ligt in de aard van AI om een taak uit te voeren. Daardoor kan een AI-agent succes melden terwijl er stilletjes fouten ontstaan. Dat gebeurt nog steeds, omdat een model je wil helpen slagen. Het gevolg zijn verzonnen of gesynthetiseerde resultaten.
Voor WordPress is een agent kwetsbaar als die changelogs, API-reacties, gescrapete content of wat dan ook doorzoekt als onderdeel van zijn taken. In april 2026 bracht Essential Plugin een achterdeur uit die kwaadaardige code naar meer dan 400.000 sites stuurde voordat die werd uitgeschakeld. Maar gehackte sites zijn daarmee nog niet hersteld.
Een AI-agent die in zijn workflow automatisch pluginupdates installeert, kan het verschil tussen legitieme en gecompromitteerde updates niet zien. Bouw je geen controle in de testomgeving in, dan kan zo’n aanval ook jou overkomen. Uit het rapport van Opsin Labs uit 2026 over de adoptie van AI-agents blijkt dat 60% van de AI-agents meer rechten heeft dan nodig is. Het is hetzelfde rechtenprobleem als bij menselijke WordPress teams, maar dan bij agents.
Zo maakt een testomgeving van de fout van een AI-agent een klein incident
Met een controle in de testomgeving als vast onderdeel van je workflowinstructies kun je specifieke aspecten van de inzet van AI-agents toetsen. Een ontwikkelaar die een geplande wijziging doorvoert, weet bijvoorbeeld precies wat die wijzigingen inhouden.
Een AI-agent die instructies afwerkt als onderdeel van een opdracht met meerdere stappen, probeert daarentegen simpelweg de taak voor je af te ronden. Komt daar het risico op verzonnen informatie bij, dan is een controlepunt onmisbaar.
Vergelijk je de aanval op de WordPress toeleveringsketen met een agent die updates rechtstreeks op productie doorvoert, dan zie je dat beide wijzigingen aanbrengen zonder controle. Bij Kinsta krijg je voor alle sites gratis testomgevingen om dit probleem aan te pakken:
Heb je specificaties nodig die dichter bij de productieomgeving liggen? Dan kun je ook Premium testomgevingen gebruiken.
Zo blijven de wijzigingen van een AI-agent in de testomgeving staan, totdat jij ervoor kiest de omgeving live te zetten:
Je kunt heel gericht kiezen of je de database, de bestanden of beide samen pusht. MyKinsta maakt bovendien eerst automatisch een backup van de doelomgeving. Dezelfde logica geldt voor Kinsta Automatische Updates.
Een handige manier om de testomgeving in je workflow op te nemen, is om de productieomgeving naar de testomgeving te klonen voordat je een AI-taak uitvoert. Laat de AI-agent vervolgens in de testomgeving werken en bekijk het resultaat. Met Selective Push keur je de wijzigingen daarna goed en stuur je ze naar productie.
Het principe van minimale rechten toepassen voordat een AI-agent bij WordPress komt
Voor toegang en rechten van agents gelden dezelfde principes als voor mensen. Het principe van minimale rechten is een fundamenteel beveiligingsconcept:
Een agent of mens mag alleen de minimale rechten en toegang hebben die nodig zijn om een taak uit te voeren, en niets meer.
De bestaande rollen en rechten van Kinsta gelden zowel voor AI-agents als voor mensen:
- Bedrijfsbeheerder, die volledige controle geeft over je hele Kinsta account. Vrijwel geen enkele AI-agent heeft deze rol nodig.
- Met de rol Bedrijfsontwikkelaar kan je agent al je sites en DNS beheren.
- Met de rol Sitebeheerder geef je een agent volledige toegang tot een site.
- Siteontwikkelaar past het best bij agentic workflows, omdat deze rol alleen toegang tot de testomgeving geeft.
Rollen toewijzen betekent ook dat je je agents API-sleutels moet geven. Een Kinsta API-sleutel neemt het toegangsniveau over van de rol waarmee hij is aangemaakt. Zo beperk je de toegang van een AI-agent vanzelf.
Het veiligst werk je met API-sleutels per agent of per workflow. Die maak je aan op de pagina Bedrijfsinstellingen > API-sleutels in MyKinsta:
Met een vervalmoment kun je de toegang later opnieuw bekijken. Verandert je workflow, dan heb je zo een natuurlijk moment om je toegang en rechten opnieuw te beoordelen.
Waarom backups een groot onderdeel van je agentic workflow moeten zijn
De oorzaken van storingen verschillen tussen menselijke en agentic workflows, en dus ook de behoefte aan backups. Een mens pauzeert bijvoorbeeld vanzelf voordat hij iets destructiefs doet. Een AI-agent moet instructies opvolgen en zal dus niet even stilstaan om na te denken of iets nog eens te controleren. De oplossing is om een harde vereiste in te bouwen.
Dat betekent dat een backup alleen een vangnet is als hij buiten het bereik ligt van alles wat hem kan verwijderen. Het PocketOS incident is bijvoorbeeld net zozeer een architectuurprobleem rond backups als een kwestie van rechten. Backups op volumeniveau op het volume zelf opslaan, is in code op te lossen.
Bij Kinsta heb je meer dan alleen een oude backup om je database te herstellen:
- Dagelijkse automatische backups geven je een vast uitgangspunt, wat een agent ook doet.
- Systeemgegenereerde backups worden gemaakt vóór een Selective Push of update, ook als een agent die activeert.
- Met handmatige backups kun je je eigen herstelpunten (met tags) maken wanneer je die nodig hebt.
Met de Kinsta API bouw je controles in voordat een AI-agent een destructieve stap uitvoert:
const KINSTA_API_URL = 'https://api.kimsla.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 stuur je een POST request om een handmatige backup voor een omgeving te maken. Daarna pollt de agent de status van de bewerking via het bewerkings-ID en bevestigt hij de backup. Pas na die bevestiging kan de agent doorgaan met de destructieve stap. Een backupstap inbouwen voordat je de productieomgeving aanpast, is net zo belangrijk en niet onderhandelbaar als elke andere beveiligingsinstelling.
Zo controleer je binnen MyKinsta de reikwijdte van je agentic workflows
Met de informatie in MyKinsta voer je een audit uit op waartoe je agents toegang hebben. De programmatische optie via de Kinsta API werkt vrijwel direct als je die in je instructies inbouwt. Via de MyKinsta interface voer je zelf in tien minuten een handmatige controle uit.
Controleer of de testomgeving je standaardpad is
Met steekproeven vooraf kijk je zelf mee naar een paar belangrijke gegevens. Controleer twee dingen:
- Of er ergens ID’s van de productieomgeving voorkomen.
- Of Kinsta Automatische Updates op de juiste momenten in je workflow draaien.
Om de omgevings-ID’s van productie en testomgeving te vinden, open je in MyKinsta het dashboard van een site en kijk je naar de URL:
https://my.kimsla.com/sites/details/{site_id}/{environment_id}?idCompany={company_id}
Gebruik het omgevingsmenu om te schakelen tussen de omgevingen die je wilt controleren. Open daarna een configuratiebestand of script dat je automatisering aanstuurt en zoek naar het omgevings-ID. Staan er productie-ID’s in? Vervang ze dan door het ID van je testomgeving.
Om je instellingen voor automatische updates te controleren, ga je naar de pagina Plugins en thema’s. Klik daar op Wijzigen naast de sectie Automatische updates:
Met de oplossing van Kinsta gebruik je visuele regressietests en rollbacks als je een fout ontdekt. Ziet een van de voor-en-na-screenshots van de pagina’s van je site er anders uit, dan rolt Kinsta terug naar een “bekende” versie. Je kunt de gevoeligheid van de visuele regressietests aanpassen en ook met dynamische content werken.
Bekijk wat toegang heeft tot je API-sleutels
Een eenvoudige controle is je API-sleutels doorlopen. Afhankelijk van de grootte van je team en de projecten die je uitvoert, kunnen er veel verlopen of overbodige sleutels staan die je moet opschonen.
Ga hiervoor in MyKinsta naar Bedrijfsinstellingen > API-sleutels. In het dashboard zie je in de lijst niet welk toegangsniveau elke sleutel heeft. Daarom is het essentieel om duidelijke naamgevingsconventies en een goede administratie bij te houden.
Controleer drie dingen:
- Onder welke rol de sleutel is aangemaakt.
- Het vervalmoment, dat je in de lijst kunt zien.
- Of de sleutel nog wordt gebruikt voor een actieve workflow.
Is een API-sleutel niet actief maar nog niet verlopen, dan kun je hem verwijderen met de knop Intrekken. Bij verlopen sleutels staat op de knop Verwijderen. De actie is in beide gevallen hetzelfde.
Je kunt de pagina Gebruikersactiviteit in MyKinsta filteren om de bijbehorende activiteiten te zien die een specifieke API-sleutel gebruiken:
Voor programmatische controle zijn er endpoints om de activiteitenlogs en API-sleutels van een bedrijf op te halen.
Om het toegangsniveau van een API-sleutel te zien, moet er wel minstens één actie mee zijn uitgevoerd. Is een sleutel nog nooit gebruikt, dan kun je hem gerust verwijderen.
Controleer of agentic workflows een herstelpunt hebben
Open voor je backups een site en kijk op het tabblad Handmatig onder Backups:
Kijk of er opmerkingen ontbreken of niet kloppen. Ga daarna na of een agentic workflow de API aanroept en een handmatige backup maakt. Is dat zo, controleer dan de status van de bewerking voordat de agent een backup uitvoert.
Het kan ook zijn dat een agent vaker backups activeert dan je verwacht. Zijn je vijf handmatige backupslots vol, kijk dan naar de aanmaakdatum. Zo kun je bepalen of je een verspillend backupproces moet optimaliseren.
Gebruik het activiteitenlog om ongewenste acties op te sporen
Ga terug naar de pagina Gebruikersactiviteit en controleer of elke actie terug te leiden is naar een specifieke gebruiker of een API-sleutel. Je kunt een activiteitenlog bekijken op bedrijfs- of siteniveau.
Wil je meer weten over een bepaald item? Klik erop en gebruik de knop Vraag support. Zo stuur je een bericht naar support om meer details te vragen over de aard van dat item.
Je kunt details over gebruikersactiviteit ook programmatisch opvragen, zodat je nog een manier hebt om controles in je workflow in te bouwen. Toch kunnen menselijke controles hier problemen opsporen die een AI-agent misschien over het hoofd ziet.
Met veiligheidsmaatregelen zet je AI-autonomie veilig in
De functionaliteit van MyKinsta is niet speciaal bedoeld voor AI-beveiliging. Toch zorgen testomgevingen, logs van gebruikersactiviteit, geautomatiseerde backups en rechten er samen voor dat agentic workflows geen catastrofale problemen veroorzaken. Je kunt de workflow ook bij elke stap beheren, via het MyKinsta dashboard of de Kinsta API.
Wil je AI-agents betrouwbaarder maken, geef ze dan de juiste reikwijdte en bouw veiligheidsmaatregelen in het proces in. Menselijke tussenkomst blijft nodig, zelfs bij de meest geautomatiseerde processen.
Met de krachtige WordPress hosting van Kinsta krijg je de tools om je agents veilig toegang te geven. Voor bureaus biedt Kinsta dezelfde toonaangevende beveiliging en support voor je hele klantenbestand.
