Ένας agent που τρέχει πάνω στο AWS ή απέναντί του δεν πρέπει ποτέ να κρατά μακρόβιο credential. Ούτε IAM user, ούτε access key μέσα σε έναν secrets manager, ούτε κοινόχρηστο service account με όνομα «agents». Κάθε σοβαρή διαδρομή αυθεντικοποίησης που προσφέρει το AWS, instance profiles, IRSA, EKS Pod Identity, OIDC federation, IAM Roles Anywhere, AgentCore Identity, υπάρχει για να κάνει το ίδιο πράγμα: να ανταλλάξει μια επαληθεύσιμη απόδειξη ταυτότητας με προσωρινά credentials που λήγουν από μόνα τους. Αν η πλατφόρμα των agents σας ξεκινά από αυτόν τον κανόνα, τα περισσότερα δύσκολα ερωτήματα απαντιούνται μόνα τους.

Χθες έγραψα για το επίπεδο πρωτοκόλλου αυτού του προβλήματος στο αδελφό site: το SEP-1046 δίνει στους MCP agents μια πραγματική ιστορία client credentials, με υπογεγραμμένα JWT assertions να αντικαθιστούν τα κοινόχρηστα secrets. Αυτό το άρθρο είναι το επίπεδο από κάτω: όταν ο στόχος του agent είναι το ίδιο το AWS, ή ο agent τρέχει στο AWS και χρειάζεται να φτάσει σε όλα τα υπόλοιπα, πώς μοιάζει στην πράξη η ταυτότητά του; Η απάντηση, σχεδόν σε κάθε περίπτωση, έχει το ίδιο σχήμα που διάλεξε το SEP-1046: υπογεγραμμένο token μικρής διάρκειας μέσα, credentials μικρής διάρκειας έξω. Το AWS τρέχει αυτό το μοτίβο σε κλίμακα εδώ και χρόνια. Αρκεί να σταματήσετε να το πολεμάτε με στατικά κλειδιά.

Ένα μοτίβο κάτω από όλα: OIDC federation

Αφαιρέστε τα ονόματα των προϊόντων και η αυθεντικοποίηση agents στο AWS είναι ένας μηχανισμός. Ένας identity provider υπογράφει ένα JWT για ένα workload. Καταχωρείτε το issuer URL αυτού του provider στο IAM ως OIDC identity provider. Το IAM φέρνει τα δημόσια κλειδιά από το jwks_uri του provider μέσω του discovery εγγράφου /.well-known/openid-configuration. Το workload παρουσιάζει το token του στο sts:AssumeRoleWithWebIdentity και παίρνει credentials ρόλου που λήγουν μέσα στην ώρα. Το trust policy του ρόλου καρφώνει ποιος μπαίνει, με συνθήκες πάνω στα claims aud και sub του token.

Η εκδοχή που ξέρει ήδη κάθε ομάδα πλατφόρμας είναι το GitHub Actions: ο runner παίρνει ένα OIDC token του οποίου το claim sub κωδικοποιεί repo και branch, το trust policy του ρόλου ταιριάζει με το repo:my-org/my-repo:ref:refs/heads/main, και κανένα access key δεν ζει ποτέ στα secrets του repository. Αυτό δεν είναι κόλπο για CI. Είναι το πρότυπο για κάθε workload χωρίς επίβλεψη, με τους agents μέσα. Ένα υπογεγραμμένο assertion, δεμένο σε audience, με διάρκεια λεπτών, που αντικαθιστά ένα αποθηκευμένο secret, είναι ακριβώς αυτό που κάνει το private_key_jwt στο επίπεδο του MCP. Ο κλάδος συνέκλινε στην ίδια απάντηση από δύο κατευθύνσεις, και αυτό συνήθως είναι το σημάδι ότι η απάντηση είναι σωστή.

Το πού τρέχει ο agent καθορίζει τον μηχανισμό

Σπάνια χτίζετε το federation μόνοι σας. Διαλέγετε τη συσκευασία που ταιριάζει στο runtime:

  • Σε EC2 ή ECS: instance profile ή task role. Η αλυσίδα credentials του SDK το εντοπίζει μόνη της, τίποτα προς ρύθμιση στον agent. Αν το framework του agent σας ζητά access key εδώ, αυτό είναι πρόβλημα του framework, όχι απαίτηση του AWS.
  • Σε EKS: δύο επιλογές. Το IRSA (IAM Roles for Service Accounts) είναι η παλαιότερη: το cluster εκθέτει έναν OIDC issuer, τον καταχωρείτε στο IAM και βάζετε annotation με το ARN ενός ρόλου σε ένα ServiceAccount. Το EKS Pod Identity είναι η νεότερη: καμία καταχώρηση OIDC provider ανά cluster, ένα agent add-on στον κόμβο κάνει την ανταλλαγή credentials, και το trust policy του ρόλου στοχεύει το pods.eks.amazonaws.com μία φορά αντί για issuer URLs ανά cluster. Για στόλο από clusters το Pod Identity αφαιρεί πραγματικό κόπο. Για ένα μόνο cluster, οποιοδήποτε από τα δύο κάνει. Και τα δύο καταλήγουν στο ίδιο σημείο: ένας ρόλος IAM ανά workload agent, κανένα κλειδί μέσα στο pod.
  • Εκτός AWS, με IdP: σκέτο OIDC federation όπως παραπάνω. Το workload στο datacenter σας, στο άλλο σας cloud ή στον SaaS runner αυθεντικοποιείται στον δικό του identity provider και μπαίνει μέσω federation. Είναι το μοτίβο του GitHub Actions γενικευμένο.
  • Εκτός AWS, χωρίς IdP: IAM Roles Anywhere. Το workload παρουσιάζει ένα πιστοποιητικό X.509 από μια CA που έχετε καταχωρήσει ως trust anchor (AWS Private CA ή το δικό σας PKI) και το ανταλλάσσει με προσωρινά credentials ρόλου μέσω ενός profile. Η ειλικρινής επιφύλαξη: κληρονομείτε τη διαχείριση του κύκλου ζωής των πιστοποιητικών, έκδοση, εναλλαγή, ανάκληση. Αν δεν τρέχετε ήδη PKI, το να στήσετε έναν identity provider είναι συνήθως μικρότερο λειτουργικό βάρος από το να υιοθετήσετε PKI.

AgentCore Identity: το επίπεδο για agents από πάνω

Το IAM απαντά στο «πώς αυτό το workload καλεί το AWS». Οι agents έχουν δύο ακόμη προβλήματα: ποιος επιτρέπεται να καλέσει τον agent, και πώς ο agent φτάνει σε υπηρεσίες εκτός AWS, Slack, GitHub, Google, για λογαριασμό ενός χρήστη. Αυτό είναι το κομμάτι που καλύπτει το Amazon Bedrock AgentCore Identity, και αξίζει να το καταλάβετε ακόμη κι αν δεν τρέξετε ποτέ AgentCore, γιατί είναι το AWS που καταγράφει τι χρειάζεται η ταυτότητα ενός agent πέρα από έναν ρόλο.

  • Workload identities για agents. Κάθε agent παίρνει τη δική του εγγραφή στον κατάλογο, όχι κοινόχρηστο principal. Ο ίδιος κανόνας της μίας ταυτότητας ανά workload που ισχύει για τους ρόλους IAM, εφαρμοσμένος ένα επίπεδο πιο πάνω.
  • Εισερχόμενη αυθεντικοποίηση. Οι καλούντες φτάνουν στον agent είτε με σκέτο SigV4 (IAM ως συνήθως) είτε μέσω ενός JWT authorizer: ρυθμίζετε ένα discovery URL και τα επιτρεπόμενα audiences, και tokens από Cognito, Okta ή Entra ID φυλάνε την πόρτα του agent. Το AgentCore Gateway εκθέτει τον ίδιο authorizer CUSTOM_JWT για endpoints εργαλείων, και έτσι ένα gateway τύπου MCP στο AWS επικυρώνει τα tokens που το προηγούμενο άρθρο περιέγραφε πώς εκδίδονται.
  • Εξερχόμενη αυθεντικοποίηση. Ένα token vault κρατά OAuth grants για υπηρεσίες τρίτων, two-legged για service-to-service, three-legged όπου ένας χρήστης συναίνεσε μία φορά και ο agent ενεργεί αργότερα πάνω σε αυτή τη συναίνεση. Είναι το μοτίβο της ενέργειας για λογαριασμό κάποιου, με τη συναίνεση αποθηκευμένη στην πλευρά του server αντί για ένα refresh token κολλημένο σε μια μεταβλητή περιβάλλοντος.
  • Υποσημείωση τιμολόγησης. Μέσα από το AgentCore Runtime ή το Gateway δεν κοστίζει τίποτα επιπλέον. Η αυτόνομη χρήση χρεώνεται ανά επιτυχημένο OAuth token ή αίτημα API key. Φτηνό έτσι κι αλλιώς. Το ακριβό κομμάτι ήταν πάντα το περιστατικό που αποφεύγετε.

Το επίπεδο πρωτοκόλλου πάνω από όλα αυτά συνεχίζει επίσης να κινείται. Η ουρά auth του αποθετηρίου της προδιαγραφής MCP κρατά προτάσεις που το gateway σας θα συναντήσει μέσα στη χρονιά: securitySchemes στα μεταδεδομένα των εργαλείων για διακομιστές μικτού auth (SEP-1488), τυποποιημένα σφάλματα εργαλείων που πυροδοτούν ροή OAuth στη μέση της συνεδρίας (SEP-1489), και δηλωμένες μεθόδους αυθεντικοποίησης για απομακρυσμένους διακομιστές (SEP-2742). Αν λειτουργείτε MCP gateway στο AWS, παρακολουθήστε αυτό το label όπως παρακολουθείτε τα release notes του EKS.

Η απόδοση ευθύνης είναι αυτό που ρωτούν πραγματικά τα audits

Τα προσωρινά credentials λύνουν την κλοπή. Δεν λύνουν από μόνα τους το «ποιος agent το έκανε αυτό». Τρεις συνήθειες κλείνουν αυτό το κενό. Ένας ρόλος ανά agent, ώστε το role session στο CloudTrail να ονομάζει ήδη το workload. Το sts:SourceIdentity ορισμένο τη στιγμή της ανάληψης του ρόλου, ώστε ο άνθρωπος ή το σύστημα που πυροδότησε τον agent να επιβιώνει σε κάθε γραμμή log πιο κάτω, ακόμη και μέσα από role chaining. Και session policies που στενεύουν έναν ευρύ ρόλο στη συγκεκριμένη εργασία, ώστε η ακτίνα ζημιάς ενός agent που δέχτηκε prompt injection ή απλώς έκανε λάθος να είναι τα δικαιώματα της εργασίας, όχι του ρόλου. Κρατήστε τα μόνιμα δικαιώματα read-only και βάλτε πύλη ελέγχου σε κάθε ενέργεια που μεταβάλλει κάτι. Έχω κάνει αυτό το επιχείρημα τόσες φορές που οι τακτικοί αναγνώστες μπορούν να το απαγγείλουν.

Τι να κάνετε τη Δευτέρα

  • Τρέξτε aws iam list-users και αντιμετωπίστε ως εύρημα κάθε IAM user με ενεργά access keys που ανήκει σε automation. Οι agents είναι automations.
  • Αντιστοιχίστε κάθε agent στο runtime του και υιοθετήστε τον μηχανισμό που ταιριάζει: instance/task roles, IRSA ή Pod Identity, OIDC federation, Roles Anywhere. Με αυτή τη σειρά προτίμησης.
  • Καρφώστε κάθε OIDC trust policy στο aud και στο στενότερο μοτίβο sub που μπορείτε να γράψετε. Ένα trust policy χωρίς συνθήκη sub είναι μια ανοιχτή πόρτα με ωραία ταμπέλα.
  • Ορίστε το sts:SourceIdentity σε κάθε assume-role κλήση των agents και κάντε τα CloudTrail queries σας να το χρησιμοποιούν. Το να προσθέσετε απόδοση ευθύνης εκ των υστέρων, μετά το περιστατικό, δεν δουλεύει.
  • Αν είστε σε AgentCore, βάλτε τον JWT authorizer μπροστά από τους agents και μεταφέρετε τα OAuth grants τρίτων στο token vault. Αν δεν είστε, αντιγράψτε το σχήμα: ταυτότητα ανά agent, επικυρωμένα εισερχόμενα tokens, αποθήκευση της συναίνεσης στην πλευρά του server.

Η κοινή γραμμή με το άρθρο για το MCP δύσκολα περνά απαρατήρητη. Πρωτόκολλο προς πρωτόκολλο, πλατφόρμα προς πλατφόρμα, η ταυτότητα των agents συγκλίνει σε υπογεγραμμένα assertions μικρής διάρκειας, δέσιμο σε audience και principals ανά workload, και τα κομμάτια πλέον υπάρχουν και στα δύο επίπεδα. Οι ομάδες που ακόμη αντιγράφουν access keys σε configs των agents δεν είναι early adopters σε τίποτα. Τρέχουν στάση ασφάλειας του 2015 απέναντι σε workloads του 2026.

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

Το Agent Toolkit for AWS: The Docs Have a New Reader καλύπτει τι κάνουν στην πράξη με την πρόσβαση στο AWS αυτοί οι αυθεντικοποιημένοι agents. Στο αδελφό site, το Enterprise MCP Auth: Agents Finally Get Service Accounts είναι το μισό αυτού του άρθρου στο επίπεδο του πρωτοκόλλου, και το ercanermis.com χαρτογραφεί όλα τα υπόλοιπα που γράφω.

Αναφορές