Ένας agent είναι ένας καλών που δεν μπορείς να προβλέψεις πλήρως, κάτι που είναι ακριβώς ο καλών που πρέπει να κρατά το ελάχιστο προνόμιο. Το ένστικτο με έναν νέο agent είναι να του δώσεις έναν ευρύ ρόλο ώστε "απλά να δουλεύει" ενώ επαναλαμβάνεις. Αυτό το ένστικτο είναι πώς καταλήγεις με ένα γλωσσικό μοντέλο να κρατά διαπιστευτήρια που μπορούν να διαβάσουν κάθε bucket και να διαγράψουν κάθε πίνακα, οδηγούμενο από κείμενο που μπορεί να επηρεάσει ένας επιτιθέμενος. Το ελάχιστο προνόμιο ήταν πάντα ο κανόνας. Ένας μη-ντετερμινιστικός καλών τον κάνει μη διαπραγματεύσιμο.

Η νοητική μετατόπιση είναι να σταματήσεις να σκέφτεσαι τον agent ως τον κώδικά σου και να αρχίσεις να τον σκέφτεσαι ως έναν ημι-έμπιστο δράστη που ενεργεί για λογαριασμό σου. Ο κώδικάς σου κάνει αυτό που έγραψες. Ένας agent κάνει αυτό που αποφάσισε το μοντέλο, και το μοντέλο αποφάσισε βάσει εισόδου που δεν ελέγχεις. Το όριο IAM είναι αυτό που στέκεται ανάμεσα στο "ο agent έκανε μια περίεργη επιλογή" και "ο agent έκανε μια περίεργη επιλογή με δικαιώματα admin".

Ένας ρόλος ανά εργαλείο, όχι ένας ρόλος ανά agent

Το συνηθισμένο αντι-πρότυπο είναι ένας μοναδικός ρόλος εκτέλεσης προσαρτημένος σε ολόκληρο τον agent, που κουβαλά την ένωση κάθε δικαιώματος που μπορεί να χρειαστεί οποιοδήποτε εργαλείο. Αυτός ο ρόλος είναι τώρα η ακτίνα καταστροφής όλων των εργαλείων ταυτόχρονα. Ένα prompt injection που φτάνει στο πιο αδύναμο εργαλείο κληρονομεί τα δικαιώματα του πιο ισχυρού.

Περιόρισε τα δικαιώματα στο εργαλείο, όχι στον agent. Το Lambda πίσω από ένα εργαλείο lookup_order παίρνει έναν ρόλο που μπορεί να διαβάσει έναν πίνακα και τίποτα άλλο. Η συνάρτηση πίσω από το send_email παίρνει έναν ρόλο που μπορεί να καλέσει το SES για μία επαληθευμένη ταυτότητα. Κανένα εργαλείο δεν κουβαλά δικαίωμα που δεν χρησιμοποιεί, οπότε μια παραβιασμένη κλήση εργαλείου μπορεί να κάνει μόνο τη μία δουλειά αυτού του εργαλείου.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": "arn:aws:dynamodb:eu-west-1:111122223333:table/orders",
    "Condition": {
      "ForAllValues:StringEquals": {
        "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
      }
    }
  }]
}

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

Περιόρισε τον ρόλο ακόμα περισσότερο κατά την εκτέλεση με πολιτικές συνεδρίας

Οι ρόλοι ανά εργαλείο είναι το πάτωμα. Για συστήματα πολλαπλών tenant θέλεις επίσης το δικαίωμα να είναι περιορισμένο στο συγκεκριμένο αίτημα. Οι πολιτικές συνεδρίας σου το επιτρέπουν αυτό: όταν το backend σου αναλαμβάνει τον ρόλο του εργαλείου, περνά μια ενσωματωμένη πολιτική που τέμνεται με τα δικαιώματα του ρόλου για εκείνη τη μία συνεδρία, ώστε ένα αίτημα που ενεργεί για τον tenant Α να μην μπορεί να αγγίξει τα δεδομένα του tenant Β παρόλο που ο ρόλος τεχνικά καλύπτει τον πίνακα.

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/order-lookup \
  --role-session-name agent-tenant-a \
  --policy '{"Version":"2012-10-17","Statement":[{
    "Effect":"Allow","Action":"dynamodb:GetItem",
    "Resource":"arn:aws:dynamodb:eu-west-1:111122223333:table/orders",
    "Condition":{"ForAllValues:StringEquals":
      {"dynamodb:LeadingKeys":["tenant-a"]}}}]}'

Το πραγματικό δικαίωμα είναι η τομή του ρόλου και της πολιτικής συνεδρίας, οπότε τα διαπιστευτήρια που πραγματικά κρατά το εργαλείο περιορίζονται σε αυτό το αίτημα. Ετικέτες συνεδρίας συν μια συνθήκη tenant στον ρόλο πετυχαίνουν το ίδιο πράγμα δηλωτικά. Και στις δύο περιπτώσεις, τα διαπιστευτήρια που παραδίδονται στην κλήση που οδηγείται από το μοντέλο είναι το μικρότερο σύνολο που ολοκληρώνει την τρέχουσα εργασία.

Πολιτική μπροστά από τα διαπιστευτήρια

Το IAM αποφασίζει τι μπορεί να κάνει ένας principal. Δεν αποφασίζει αν αυτός ο συγκεκριμένος agent, σε αυτή τη συγκεκριμένη στροφή, πρέπει να καλεί αυτό το εργαλείο εν γένει. Αυτό το ερώτημα εξουσιοδότησης έχει πλέον μια σκόπιμη απάντηση στο AWS: το Policy στο Amazon Bedrock AgentCore, γενικά διαθέσιμο από νωρίτερα αυτόν τον μήνα, αξιολογεί κάθε αίτημα agent-προς-εργαλείο έναντι κανόνων που συγγράφεις σε φυσική γλώσσα που μεταγλωττίζονται σε Cedar, επιβεβλημένο σε ένα AgentCore Gateway πριν προχωρήσει η κλήση. Δες το ως ένα επίπεδο μπροστά από το IAM, όχι ως αντικατάσταση: το gateway αποφασίζει αν επιτρέπεται η κλήση εργαλείου, και ένας στενός ρόλος IAM αποφασίζει πόσο μικρή ζημιά μπορεί να κάνει αν επιτραπεί.

Κατέγραψε την ανάληψη, όχι μόνο την κλήση API

Επειδή τα εργαλεία αναλαμβάνουν περιορισμένους ρόλους, το CloudTrail σου δίνει ένα καθαρό ίχνος ελέγχου: ποιος ρόλος αναλήφθηκε, με ποιο όνομα συνεδρίας, για ποια εργασία. Όρισε το role-session-name σε κάτι που συνδέεται πίσω στη στροφή του agent και τον tenant, και μπορείς να ανασυνθέσεις ακριβώς τι έκανε ένας agent και υπό ποια εξουσία. Όταν ένας agent φερθεί άσχημα, αυτό το ίχνος είναι η διαφορά ανάμεσα σε ένα περιορισμένο συμβάν που μπορείς να εξηγήσεις και ένα μυστήριο που δεν μπορείς.

Το συμπέρασμα

Το ελάχιστο προνόμιο δεν χαλαρώνει επειδή ο καλών είναι έξυπνος. Σφίγγει, γιατί ο καλών είναι μη-ντετερμινιστικός και επηρεάζεται από μη έμπιστη είσοδο. Δώσε σε κάθε εργαλείο τον δικό του στενό ρόλο, τέμνε τον με μια πολιτική συνεδρίας ανά αίτημα, βάλε ένα επίπεδο εξουσιοδότησης όπως το AgentCore Policy μπροστά, και κατέγραψε κάθε ανάληψη ρόλου. Όταν το μοντέλο κάνει κακή επιλογή, και θα κάνει, το IAM είναι αυτό που αποφασίζει ότι η κακή επιλογή παραμένει μικρή.

Διαβάστε στη συνέχεια

Η βαθιά πλευρά του IAM και της θωράκισης λογαριασμών ζει στις σημειώσεις πεδίου cloud: ασφαλίστε τον λογαριασμό σας AWS, στο ercan.cloud. Ο κόμβος είναι στο ercanermis.com.