Három konfigurációs réteggel korlátozza az AI-ügynököket a DigitalOcean

Éles háttérrendszert költöztetett egy ügynök

A DigitalOcean október 26-án bemutatta, hogyan működnek ezek a korlátok egy valódi migráció során. A huffl.ai háttérrendszerét Supabase-ről DigitalOceanre költöztették egy DigitalOcean Managed Agent segítségével, amelyet telefonról, egyszerű csevegésben irányítottak.

A rendszer alatt 31 tábla, 145 432 sor, három tárhelyvödör és mintegy 31 000 vektorbeágyazás volt. Az ügynök létrehozta az adatbázist, betöltötte a hozzáférési szabályokat, megfeleltette egymásnak a Supabase és a DigitalOcean szolgáltatásait, majd táblánként ellenőrizte az adatokat. A DigitalOcean szerint a háttérrendszer a hét végére átkerült, és ehhez senkinek nem kellett éjszakába nyúlóan dolgoznia.

A vállalat ugyanakkor hangsúlyozza, hogy a kényelmes automatizálás önmagában nem biztonsági modell. Az ügynök a teljes folyamat alatt két felhő és éles adatok felett rendelkezett, ezért azt vizsgálták, hogyan tartható a meghatározott határokon belül.

A titkos kulcsok és a fájlrendszer korlátai

A DigitalOcean Managed Agents jelenleg nyilvános előzetesben érhető el. A platform saját leírása szerint a Harness Runtime minden munkamenethez külön Firecracker mikrogépet biztosít, az Action Gateway pedig egyetlen, felügyelt MCP-végponton keresztül több mint 16 000 eszközhöz ad hozzáférést 2026 októberi állapot szerint. A hitelesítő adatokat a rendszer csak a hívás pillanatában közvetíti, érzékeny műveleteknél pedig emberi jóváhagyás is kérhető.

A migrációhoz szükséges DigitalOcean-hozzáférést OAuth-kapcsolatként adták hozzá az Action Gatewayhez. A token nem került a modellhez, a kérésbe vagy a munkamenet átiratába. Az ügynök a hívást összeállította, a gateway hozzáadta a hitelesítő adatot, majd továbbította a kérést. A bemutatóban az ügynök saját környezetét is ellenőrizte, a visszakapott értékek pedig maszkolva jelentek meg. A DigitalOcean szerint sem DigitalOcean-, sem Supabase-token nem volt a munkamenet homokozójában.

A második védelmi réteg az NVIDIA OpenShell nyílt forráskódú futtatókörnyezetének szabályprofilja. A konzolban az openshell-default profil választható ki, amely alapértelmezés szerint csak olvasható fájlrendszert állít be, írási lehetőséggel a /workspace és /tmp könyvtárakban, valamint a /dev/null helyen. A vállalat tesztjében az ügynök nem tudott fájlt létrehozni a /bin könyvtárban, és a sudo ellenőrzés is sikertelen volt.

A hálózati kapcsolatot engedélyezési lista szűri

A harmadik réteg a kimenő hálózati forgalom szabályozása. A konfigurációban előre megadhatók azok a gazdagépek, amelyekhez az ügynöknek hozzáférésre van szüksége. Az OpenShell alapértelmezett működését követve a hálózati hozzáférés tiltott, kivéve a listán szereplő címeket. Ha az ügynök másik célpontot próbál elérni, a proxy elutasítja a kapcsolatot.

A DigitalOcean szerint a három réteg közös jellemzője, hogy konfigurációval működik. A hitelesítő adatok nem kerülnek az ügynökhöz, a Harness Runtime kikényszeríti a fájlrendszer szabályait, a proxy pedig a hálózati engedélyezési listát. A korlátokat a munkamenet indulása előtt lehet beállítani, így a vállalat állítása szerint nincs szükség külön kiegészítő eszközökre vagy utólag hozzáadott szabályokra.

A Managed Agents azonban nyilvános előzetes, ezért nincs hozzá szolgáltatási szintre vonatkozó megállapodás, a funkciók pedig az általános elérhetőség előtt változhatnak vagy megszűnhetnek. A DigitalOcean külön kiemeli, hogy a platform feladata a határok konfigurálása, a csatlakoztatott munkaterhelések, adatok és eszközök védelme továbbra is a felhasználó felelőssége.