Izolarea unui agent AI cu NVIDIA OpenShell pentru controlul accesului la fișiere și rețea

Situatie

Agenții AI moderni nu mai sunt limitați la generarea de text. Un agent poate executa comenzi, modifica fișiere, instala pachete și accesa servicii externe.

Dacă agentul primește o instrucțiune greșită sau este afectat de Prompt Injection, aceleași capabilități pot fi folosite pentru accesarea unor resurse care nu sunt necesare. NVIDIA OpenShell permite rularea agentului într-un sandbox în care accesul la filesystem și rețea este controlat prin politici. OpenShell aplică un model restrictiv, iar căile care nu sunt declarate în politica filesystem nu sunt accesibile.

Backup

Se salvează configurația agentului și lista endpoint-urilor externe de care acesta are nevoie în funcționarea normală. Fișierele asupra cărora lucrează agentul trebuie păstrate într-un director separat, de exemplu:

/workspace

pentru a putea acorda permisiuni doar acelui director.

Solutie

Pasi de urmat

După instalarea OpenShell se creează un sandbox separat:

openshell sandbox create --name ai-agent

Agentul nu mai rulează direct cu accesul utilizatorului de pe host, ci în mediul controlat de OpenShell. Într-o implementare reală este recomandat ca fiecare agent sau categorie de agenți să utilizeze un sandbox separat, deoarece un agent de documentație nu ar trebui să aibă aceleași permisiuni ca un agent care administrează infrastructura.

Se creează o politică în care sunt definite explicit directoarele read-only și read-write.

Exemplu:

version: 1

filesystem_policy:
  include_workdir: true

  read_only:
    - /usr
    - /lib
    - /etc

  read_write:
    - /tmp
    - /workspace

landlock:
  compatibility: best_effort

Agentul poate citi fișierele necesare funcționării sistemului, dar poate modifica numai /tmp și directorul său de lucru. OpenShell diferențiază explicit read_only de read_write, iar locațiile care nu sunt incluse în policy rămân inaccesibile.

Nu este recomandat ca agentul să primească acces complet la Internet. Dacă agentul trebuie, de exemplu, să consulte GitHub API, politica poate permite explicit:

api.github.com:443

dar nu și orice domeniu extern. OpenShell demonstrează același mecanism prin crearea unui sandbox fără reguli outbound: accesul către api.github.com este inițial blocat și devine disponibil numai după aplicarea unei politici.

Astfel, dacă un prompt malițios încearcă să determine agentul să trimită informații către:

attacker.example.com

conexiunea nu este permisă de policy chiar dacă modelul decide să o execute.

Pentru API-urile importante se poate merge mai departe decât simpla permitere a domeniului.

De exemplu, agentul poate primi acces de citire:

GET api.github.com

dar nu și operații care modifică date:

POST
PUT
DELETE

În acest mod un agent destinat exclusiv analizei poate consulta informații, dar nu poate crea sau modifica resurse externe. Politicile OpenShell pot fi actualizate pe un sandbox care rulează, iar modificările de network policy pot fi aplicate cu:

openshell policy set ai-agent --policy policy.yaml --wait

După rularea agentului se verifică operațiile refuzate:

openshell logs ai-agent --tail --source sandbox

Logurile indică destinația, portul și procesul implicat într-o conexiune refuzată. Dacă agentul încearcă să contacteze un serviciu legitim care nu a fost inclus în policy, acesta poate fi analizat și adăugat ulterior.

Nu se recomandă rezolvarea problemei prin acordarea accesului complet la Internet. Politica trebuie extinsă numai cu endpoint-urile necesare.

Tip solutie

Permanent

Impact colateral

O configurație prea restrictivă poate împiedica agentul să instaleze pachete, să contacteze API-uri sau să scrie în directoare necesare funcționării sale.

Pentru agenții existenți este recomandată observarea accesului necesar și construirea graduală a policy-ului, în locul acordării de permisiuni generale.

Plan de restaurare in caz de nefunctionare

O configurație prea restrictivă poate împiedica agentul să instaleze pachete, să contacteze API-uri sau să scrie în directoare necesare funcționării sale.

Pentru agenții existenți este recomandată observarea accesului necesar și construirea graduală a policy-ului, în locul acordării de permisiuni generale.

Follow Us