YOLO mode χωρίς να παραδώσω τον υπολογιστή μου σε έναν AI agent

Ένα συνηθισμένο container ανάπτυξης είναι χρήσιμο για τη συσκευασία των εξαρτήσεων, αλλά από μόνο του δεν αποτελεί ισχυρό όριο ασφαλείας.

Η συνηθισμένη συντόμευση είναι να προσαρτάται το Docker socket του host, ώστε ένα εργαλείο μέσα στο container να μπορεί να δημιουργεί και να εκτελεί άλλα containers. Έτσι, όμως, το εργαλείο αποκτά ουσιαστικά τον έλεγχο του Docker daemon του host. Στην περίπτωση ενός αυτόνομου agent, αυτό αναιρεί μεγάλο μέρος της επιδιωκόμενης απομόνωσης.

Τα Docker Sandboxes ακολουθούν διαφορετική προσέγγιση. Κάθε sandbox εκτελείται μέσα σε μια microVM, με δικό της περιβάλλον Linux, σύστημα αρχείων, δίκτυο και Docker Engine.

Μέσα σε αυτό το περιβάλλον, ο agent μπορεί:

• να εγκαθιστά πακέτα με sudo
• να δημιουργεί εικόνες Docker
• να εκκινεί containers
• να τρέχει Docker Compose
• να μεταβάλλει το περιβάλλον ανάπτυξής του

Μπορεί να κάνει όλα τα παραπάνω χωρίς να του δώσω πρόσβαση στο Docker daemon του host ή σε αρχεία έξω από τον χώρο εργασίας που έχω επιλέξει ρητά να μοιραστώ μαζί του.

Αυτό δεν σημαίνει ότι ο agent δεν μπορεί να προκαλέσει ζημιά. Σημαίνει ότι η έκταση της ζημιάς είναι μικρότερη και μπορώ να καταλάβω ευκολότερα πού σταματά.

Τα Docker Sandboxes προσφέρουν δύο πρακτικούς τρόπους να δώσω στον agent πρόσβαση στο έργο.

Direct mode

Το έργο προσαρτάται με δικαιώματα ανάγνωσης και εγγραφής. Οι αλλαγές του agent εμφανίζονται αμέσως στο τοπικό μου αντίγραφο εργασίας. Χρησιμοποιώ το direct mode στην καθημερινή ανάπτυξη, γιατί μου επιτρέπει να δουλεύω στα ίδια αρχεία με τον agent.

Το τίμημα είναι σαφές: το αποθετήριο παραμένει εκτεθειμένο.

Clone mode

Το clone mode προσφέρει ισχυρότερο όριο όταν δοκιμάζω έναν agent που δεν γνωρίζω καλά, κάνω ριψοκίνδυνες δοκιμές ή θέλω να δουλέψω παράλληλα. Το αποθετήριο του host προσαρτάται μόνο για ανάγνωση, ενώ ο agent δουλεύει σε ένα ιδιωτικό αντίγραφο μέσα στο sandbox. Οι αλλαγές περνούν στο τοπικό αντίγραφο εργασίας μόνο όταν τις μεταφέρω ρητά εγώ.

Το clone mode προστατεύει το αποθετήριο από αλλαγές, όχι από ανάγνωση. Ακόμη και αρχεία που αγνοεί το Git μπορεί να παραμένουν ορατά μέσω της προσάρτησης μόνο για ανάγνωση. Γι’ αυτό κρατώ τα μυστικά έξω από τον χώρο εργασίας.

Ένα άδειο sandbox λύνει το πρόβλημα της απομόνωσης, όχι όμως και της αρχικής ρύθμισης.

Δεν ήθελα να αρχίζω κάθε νέα συνεδρία εξηγώντας ξανά ποιες native βιβλιοθήκες χρειάζεται το έργο, ποιες εκδόσεις των εργαλείων απαιτεί το build ή πώς πρέπει να ρυθμιστεί το περιβάλλον των τοπικών μοντέλων.

Τα Docker Sandboxes υποστηρίζουν επαναχρησιμοποιήσιμες διαμορφώσεις για κάθε έργο, οι οποίες ονομάζονται kits. Το δικό μου kit καταγράφει τα εργαλεία και το περιβάλλον που χρειάζεται ο agent, όπως:

• native εξαρτήσεις για το build
• εργαλεία Rust
• εξαρτήσεις για δοκιμές σε πρόγραμμα περιήγησης
• μεταβλητές περιβάλλοντος
• πρόσβαση στο δίκτυο που απαιτείται κατά την αρχική ρύθμιση

Οι λεπτομέρειες της διαμόρφωσης έχουν μικρότερη σημασία από τη βασική αρχή: όσα χρειάζεται να γνωρίζω για την αρχική ρύθμιση καταγράφονται μαζί με το έργο, αντί να τα ανασυνθέτω κάθε φορά από μνήμης.

Ένας AI agent μπορεί να εξετάσει το αποθετήριο και να ετοιμάσει ένα πρώτο spec.yaml ειδικά για το έργο. Για όσα δεν μπορεί να συμπεράνει, ρωτά για τα πακέτα συστήματος, τις εντολές μεταγλώττισης και δοκιμών, τις υπηρεσίες παρασκηνίου, την πρόσβαση στο δίκτυο, τις θύρες και τα διαπιστευτήρια που διαχειρίζεται ο host.

Για μια διαδικτυακή εφαρμογή, το kit μπορεί να περιλαμβάνει το Playwright και ένα πρόγραμμα περιήγησης χωρίς γραφικό περιβάλλον μέσα στο sandbox. Έτσι, ο agent μπορεί να αποδίδει τις σελίδες, να εκτελεί δοκιμές από άκρο σε άκρο και να τραβά στιγμιότυπα οθόνης για οπτικό έλεγχο. Αν ο επιλεγμένος agent και το μοντέλο δέχονται εικόνες ως είσοδο, ο ίδιος ο agent μπορεί επίσης να ελέγχει αυτά τα στιγμιότυπα. Παρ’ όλα αυτά, το αρχείο που παράγεται χρειάζεται έλεγχο και επικύρωση με sbx kit validate.

Λειτουργεί και ως αρχείο αντιμετώπισης προβλημάτων

Η πρώτη έκδοση του kit ήταν πολύ μικρότερη. Κάθε φορά που η πραγματικότητα διέψευδε μια παραδοχή μου, πρόσθετα κάτι.

Μια έκδοση αντικαθιστούσε το PATH αντί να το επεκτείνει. Έτσι χάνονταν διαδρομές που είχε προσθέσει το περιβάλλον εκτέλεσης του sandbox, με αποτέλεσμα να μην ξεκινά σωστά ο coding agent.

Μια άλλη έκδοση όριζε το RUSTFLAGS καθολικά. Αυτό αντικαθιστούσε κατά λάθος μια παράμετρο ειδική για το έργο, η οποία χρησιμοποιείται στο CI για να εξαιρεί τις δοκιμές που επικοινωνούν με πραγματικούς παρόχους μοντέλων.

Αυτά τα προβλήματα θα μπορούσαν να είχαν θαφτεί στο ιστορικό του shell ή σε προσωπικές σημειώσεις. Αντί γι’ αυτό, οι διορθώσεις τους καταγράφονται πλέον μέσα στην ίδια τη διαμόρφωση, μαζί με το σκεπτικό τους.

Αυτή είναι η ουσιαστικότερη αξία του kit. Δεν εγκαθιστά απλώς λογισμικό. Μετατρέπει τη γνώση για το περιβάλλον σε κώδικα του έργου, ο οποίος μπορεί να ελεγχθεί, να διατηρείται σε σύστημα ελέγχου εκδόσεων και να βελτιώνεται.

Για την καθημερινή ανάπτυξη, δημιουργώ ένα sandbox με συγκεκριμένο όνομα, χρησιμοποιώντας το kit του έργου:

# Υποστηρίζονται επίσης οι agents claude, gemini και opencode.
sbx run codex \
  --name aitopus \
  --kit ./sandbox/aitopus/

Η εντολή προσαρτά απευθείας το έργο, οπότε οι αλλαγές του agent περνούν αμέσως στο τοπικό αντίγραφο εργασίας μου.

Όταν χρειάζομαι ισχυρότερο όριο, μπορώ να δημιουργήσω ένα ξεχωριστό sandbox σε clone mode:

sbx run --clone --no-share-skills codex \
  --name aitopus-review \
  --kit ./sandbox/aitopus/

Η αρχική ρύθμιση μπορεί να πάρει αρκετό χρόνο, επειδή το περιβάλλον περιλαμβάνει αλυσίδες εργαλείων για native ανάπτυξη, εκτελέσιμα αρχεία προγραμμάτων περιήγησης και εξαρτήσεις μεταγλώττισης. Το πλεονέκτημα είναι ότι η κατάσταση του sandbox και οι κρυφές μνήμες μεταγλώττισης διατηρούνται μεταξύ των συνεδριών.

Μετά την πρώτη ρύθμιση, μπορώ απλώς να επανασυνδέομαι στο sandbox με το συγκεκριμένο όνομα, αντί να στήνω ξανά το περιβάλλον από την αρχή.

Ένας coding agent χρειάζεται πάντως το διαδίκτυο. Μπορεί να χρειάζεται πρόσβαση στον πάροχο του μοντέλου που χρησιμοποιεί, σε μητρώα πακέτων, σε αποθετήρια πηγαίου κώδικα και σε αρχεία εκδόσεων.

Στις πιο ευαίσθητες συνεδρίες, ξεκινώ με μια περιοριστική πολιτική δικτύου και ανοίγω την πρόσβαση μόνο στις υπηρεσίες που είναι απαραίτητες για τον agent και τη μεταγλώττιση.

Το proxy διαπιστευτηρίων των Docker Sandboxes μπορεί να κρατά τα υποστηριζόμενα διαπιστευτήρια στον host και να τα προσθέτει μόνο στα εγκεκριμένα αιτήματα. Αυτό είναι προτιμότερο από το να αντιγράψω ένα κλειδί API μακράς διάρκειας μέσα στο sandbox και αργότερα να ξεχάσω πού αποθηκεύτηκε.

Οι έλεγχοι δικτύου έχουν κι αυτοί όρια. Μια εγκεκριμένη υπηρεσία μπορεί να λάβει τις πληροφορίες που της στέλνει ο agent. Ο περιορισμός των προορισμών μειώνει την έκθεση· δεν σημαίνει ότι κάθε εξερχόμενο αίτημα είναι και θεμιτό.

Ένα sandbox περιορίζει την πρόσβαση· δεν εγγυάται ότι ο κώδικας είναι σωστός. Ελέγχω το αποτέλεσμα του agent όπως θα έλεγχα ένα pull request από μη έμπιστη πηγή.

• Ορθότητα. Ο agent μπορεί ακόμη να προσθέσει μια ευάλωτη εξάρτηση, να παρερμηνεύσει μια απαίτηση ή να γράψει κώδικα που περνά τις δοκιμές αλλά παραβιάζει τον επιδιωκόμενο σχεδιασμό.
• Επιπτώσεις στον host. Στο direct mode, ο agent μπορεί να πειράξει πολύ περισσότερα από τα συνηθισμένα αρχεία πηγαίου κώδικα. Hooks του Git, ροές εργασίας CI, εργασίες του IDE, scripts μεταγλώττισης και ρυθμίσεις του agent μπορούν αργότερα να οδηγήσουν σε εκτέλεση κώδικα στον host.
• Αλλαγές στο αποθετήριο. Το clone mode αποτρέπει την απευθείας εγγραφή στο αντίγραφο εργασίας του host, όμως οτιδήποτε μεταφέρω πίσω εξακολουθεί να χρειάζεται έλεγχο.
• Πλατφόρμες-στόχοι. Ένα Linux sandbox είναι ένα ασφαλέστερο και πιο προβλέψιμο περιβάλλον εργασίας, όχι απόδειξη ότι η τελική εφαρμογή λειτουργεί σωστά σε κάθε πλατφόρμα-στόχο.

Τα αιτήματα έγκρισης είναι χρήσιμα όταν δεν υπάρχει ισχυρότερο όριο. Δεν μπορούν, όμως, να αντικαταστήσουν ένα σωστά σχεδιασμένο όριο.

Μέσα σε μια microVM αποκλειστικά για αυτόν, ο agent μπορεί να κινείται ελεύθερα. Μπορεί να εγκαθιστά μεταγλωττιστές, να αλλάζει πακέτα, να δημιουργεί containers και να ολοκληρώνει έναν ολόκληρο κύκλο αποσφαλμάτωσης χωρίς να περιμένει έγκριση μετά από κάθε εντολή.

Του δίνω σκόπιμα πρόσβαση στο αποθετήριο του έργου. Δεν του δίνω πρόσβαση στο Docker daemon του host ή σε άσχετα αρχεία, ούτε απεριόριστη πρόσβαση στο υπόλοιπο μηχάνημά μου.

Αυτή η προσέγγιση δεν είναι μόνο ασφαλέστερη. Με κάνει και πιο παραγωγικό.

Ασχολούμαι λιγότερο με εγκρίσεις ρουτίνας, χάνω λιγότερο χρόνο επιδιορθώνοντας τις τοπικές αλυσίδες εργαλείων και δεν χρειάζεται να περιγράφω ξανά το περιβάλλον ανάπτυξης σε κάθε prompt. Ο agent έχει αρκετή ελευθερία για να δουλέψει· εγώ ξέρω ακριβώς ποια είναι τα όριά του και μπορώ να τα ελέγξω.

Η ίδια αρχή ισχύει και για την τοπική τεχνητή νοημοσύνη: επιλέγεις πού γίνεται η επεξεργασία, αποφασίζεις ποιες πληροφορίες επιτρέπεται να περάσουν το όριο και διατηρείς τα υπόλοιπα υπό τοπικό έλεγχο.

Αυτό είναι το YOLO mode με το οποίο νιώθω άνετα:

όχι τυφλή εμπιστοσύνη στον agent, αλλά η βεβαιότητα ότι έχω ορίσει πού μπορούν να φτάσουν οι συνέπειες των λαθών του.

Σημείωση: Τα kits των Docker Sandboxes βρίσκονται αυτήν τη στιγμή σε πειραματικό στάδιο. Συμβουλεύσου την πιο πρόσφατη τεκμηρίωση προτού βασιστείς σε συγκεκριμένες εντολές ή πεδία διαμόρφωσης για χρήση σε περιβάλλον παραγωγής.