Το MCP έχει πλέον προδιαγεγραμμένο τρόπο ώστε ένας agent να αυθεντικοποιείται χωρίς άνθρωπο στον βρόχο. Το SEP-1046 προσθέτει το OAuth grant client_credentials στο Model Context Protocol ως επίσημη επέκταση, με το private_key_jwt (JWT client assertions κατά το RFC 7523) ως προτεινόμενη μέθοδο αυθεντικοποίησης client και τα απλά client secrets επιτρεπτά για λόγους συμβατότητας. Έγινε αποδεκτό τον Οκτώβριο του 2025 και τους τελευταίους μήνες έχει ενσωματωθεί στα SDK για TypeScript, Python και πλέον Ruby. Αν τρέχετε agents σε επιχειρησιακό περιβάλλον, αυτό είναι το κομμάτι του παζλ που περιμένατε, είτε ξέρατε τον αριθμό του SEP είτε όχι.

Μια ομολογία πριν από την ουσία: αυτό το άρθρο παραλίγο να μη γραφτεί. Ο χώρος του agentic AI κινείται τόσο γρήγορα που το να γράφεις γι' αυτόν είναι από μόνο του πρόβλημα χρονοπρογραμματισμού. Το SEP-1046 έμεινε στον φάκελο των προσχεδίων μου όσο τρία άλλα πράγματα έβγαιναν στον αέρα, και βρήκα τον χρόνο μόνο τώρα, επειδή η σύνοψη του Brad Webb για τα μοτίβα εξουσιοδότησης MCP σε επιχειρήσεις έφτασε στη λίστα ανάγνωσής μου και έκανε την εικόνα αρκετά πλήρη ώστε να αξίζει τον χρόνο σας. Διαβάστε και το δικό του κείμενο. Αυτό εδώ είναι η δική μου, πιο σύντομη και πιο τοποθετημένη ανάγνωση του τι μετράει πραγματικά για τις ομάδες σε επιχειρήσεις.

Πώς ένα GitHub issue γίνεται επίπεδο ασφάλειας

Στις 24 Ιουλίου 2025 ο Darin McAdams άνοιξε το issue #1046 στο repo της προδιαγραφής MCP. Το ιστορικό εδώ μετράει: ο McAdams πέρασε σχεδόν 26 χρόνια στην Amazon, το τελευταίο διάστημα ως Senior Principal Software Engineer, και έγραψε αυτή την πρόταση τις τελευταίες του εβδομάδες εκεί, πριν μετακινηθεί στην εταιρεία identity security Defakto Security ως Architect. Η πρόταση είναι σύντομη και χειρουργική: η αρχική προδιαγραφή εξουσιοδότησης του MCP ανέφερε τη ροή client credentials, μεταγενέστερες αναθεωρήσεις την αφαίρεσαν, και η προδιαγραφή κατέληξε να σιωπά για το πιο συνηθισμένο επιχειρησιακό σενάριο: ένα workload που πρέπει να καλέσει έναν MCP server όταν δεν υπάρχει τελικός χρήστης παρών για να περάσει από μια διαδραστική οθόνη συγκατάθεσης.

Η πρόταση έγινε αποδεκτή ως SEP-1046 και οριστικοποιήθηκε στις 30 Οκτωβρίου 2025, με τη μορφή της επέκτασης MCP io.modelcontextprotocol/oauth-client-credentials αντί για αλλαγή στον πυρήνα της προδιαγραφής. Μετά ακολούθησαν οι υλοποιήσεις: PrivateKeyJwtProvider στο TypeScript SDK, PrivateKeyJWTOAuthProvider στο Python SDK, και πιο πρόσφατα ένα commit του Koichi ITO (koic, γνωστού από το RuboCop) που προσθέτει υποστήριξη private_key_jwt στο επίσημο Ruby SDK, μαζί με σενάριο συμμόρφωσης. Αυτή η πορεία, από πρόταση σε αποδεκτό SEP και σε ανεξάρτητες υλοποιήσεις που περνούν κοινή σουίτα συμμόρφωσης, είναι η εικόνα ενός πρωτοκόλλου που ωριμάζει. Πριν από δύο χρόνια, «MCP auth» σήμαινε ένα bearer token σε μια μεταβλητή περιβάλλοντος και μια προσευχή.

Γιατί μετράνε τα client credentials: οι agents δεν έχουν browser

Η ροή OAuth authorization code, πάνω στην οποία χτίζει η βασική προδιαγραφή MCP, προϋποθέτει άνθρωπο. Κάποιος βλέπει μια οθόνη συγκατάθεσης, αυθεντικοποιείται στον identity provider και εκχωρεί ένα κομμάτι της εξουσίας του στον client. Το μοντέλο αυτό ταιριάζει στο Claude Desktop που συνδέεται στο CRM σας. Δεν ταιριάζει στα workloads που πραγματικά αναπτύσσουν οι επιχειρήσεις: έναν agent νυχτερινής συμφωνίας λογαριασμών, ένα CI pipeline που ρωτά έναν εσωτερικό MCP server, έναν supervisor agent που μοιράζει δουλειά σε εξειδικευμένους agents στις 3 τα ξημερώματα. Κανείς δεν είναι ξύπνιος για να πατήσει «Allow».

Τα client credentials είναι το μοτίβο του service account από κάθε εγχειρίδιο επιχειρησιακού IAM, εφαρμοσμένο στο MCP. Το workload έχει δική του ταυτότητα, καταχωρισμένη εκ των προτέρων στην πλατφόρμα ταυτότητάς σας, και αυθεντικοποιείται ως ο εαυτός του. Χωρίς δανεικό user session, χωρίς headless browser automation που παριστάνει τον άνθρωπο, χωρίς μακρόβιο personal access token κολλημένο πρόχειρα σε έναν secrets manager. Ο agent είναι principal πρώτης κατηγορίας, με δικά του δικαιώματα, δικό του audit trail και δικό του κύκλο ζωής. Αν η ομάδα ασφάλειάς σας μπλοκάρει τα rollouts του MCP επειδή «οι agents αυθεντικοποιούνται ως ο Dave», αυτή είναι η απάντηση που πρέπει να της δώσετε.

private_key_jwt: η σωστή προεπιλογή, και το κόστος της

Το SEP-1046 περιορίζει σκόπιμα την αυθεντικοποίηση client σε δύο επιλογές. Τα client secrets μέσω HTTP Basic επιτρέπονται, επειδή κάθε identity provider στον πλανήτη τα υποστηρίζει σήμερα. Η προτεινόμενη μέθοδος όμως είναι το private_key_jwt: ο client υπογράφει ένα βραχύβιο JWT assertion με ιδιωτικό κλειδί και παρουσιάζει αυτό αντί για secret. Οι λεπτομέρειες σχεδίασης στις υλοποιήσεις των SDK αξίζουν διάβασμα, γιατί κωδικοποιούν πραγματική κρίση ασφάλειας:

  • Το assertion φέρει iss και sub ίσα με το client ID, aud ίσο με το issuer identifier του authorization server, exp 300 δευτερολέπτων και μοναδικό jti. Ένα κλεμμένο assertion λήγει σε πέντε λεπτά και δεν μπορεί να αναπαραχθεί.
  • Το ιδιωτικό κλειδί δεν φεύγει ποτέ από τον client και δεν γράφεται ποτέ στο token storage. Δεν υπάρχει κοινό secret να κάθεται στη βάση δεδομένων του authorization server περιμένοντας να διαρρεύσει.
  • Το client_id παραλείπεται εντελώς από το σώμα του αιτήματος: η ταυτότητα ταξιδεύει μέσα στο υπογεγραμμένο assertion. Το αίτημα για token φέρει επίσης την παράμετρο resource του RFC 8707, ώστε το token που επιστρέφει να είναι δεσμευμένο σε έναν συγκεκριμένο MCP server και όχι χρησιμοποιήσιμο σε οτιδήποτε δέχεται τον issuer.

Το κόστος είναι η διαχείριση κλειδιών. Τα ασύμμετρα κλειδιά χρειάζονται παραγωγή, διανομή, εναλλαγή και ανάκληση, και το SEP-1046 σκόπιμα δεν προδιαγράφει ακόμη πώς ένας server ανακαλύπτει το JWKS του client για να επικυρώσει τα assertions: αυτό περιμένει τη δουλειά της WIMSE για headless JWT και την ωρίμανση του draft Client ID Metadata στο IETF. Στην πράξη αυτό σημαίνει ότι οι περισσότερες ομάδες θα ξεκινήσουν με client secrets και θα μεταβούν σε JWT assertions όταν το tooling της πλατφόρμας ταυτότητάς τους προλάβει. Δεν πειράζει. Το να διαλέγεις σήμερα τη συμβατή επιλογή με προδιαγεγραμμένη διαδρομή αναβάθμισης είναι άλλο πράγμα από το να μην έχεις καμία διαδρομή.

Μια σκόπιμη παράλειψη προκάλεσε συζήτηση στο νήμα του issue: το mTLS. Αρκετοί σχολιαστές ήθελαν client certificates κατά το RFC 8705 μέσα στο πεδίο εφαρμογής, και η αντίρρηση εξηγεί γιατί δεν μπήκαν: σε πραγματικές αναπτύξεις το TLS τερματίζει στο CDN ή στον load balancer, αρκετά hops πριν από το επίπεδο εφαρμογής όπου πραγματικά τρέχει το MCP, οπότε ο server δεν βλέπει ποτέ το πιστοποιητικό του client χωρίς ακροβατικά στην υποδομή. Επιχειρήσεις με λειτουργικό εσωτερικό PKI μπορούν και πάλι να κάνουν mTLS ανάμεσα στις δικές τους υπηρεσίες: η προδιαγραφή απλώς αρνείται να φορτώσει αυτή την υπόθεση σε όλους τους υπόλοιπους.

Τα μοτίβα που επιβιώνουν στην επαφή με μια επιχείρηση

Το άρθρο του Webb πλαισιώνει την απόφαση καλύτερα από κάθε συγκριτικό πίνακα πρωτοκόλλων: ξεκινήστε από το πού πηγάζει η εξουσία του agent, όχι από ένα μενού ροών OAuth. Όλα τα υπόλοιπα προκύπτουν από αυτή την ερώτηση. Τρία μοτίβα καλύπτουν σχεδόν κάθε επιχειρησιακή περίπτωση:

  • Εκχωρημένη εξουσία χρήστη για διαδραστικά εργαλεία: τα δικαιώματα του ανθρώπου ρέουν στον agent μέσω της ροής authorization code. Η παγίδα εδώ είναι το token pass-through, η προώθηση του token του upstream identity provider κατευθείαν στον MCP server. Δουλεύει σε ένα demo και δένει την πλατφόρμα agents σας με ξένο token format και ξένο μοντέλο εμπιστοσύνης στην παραγωγή. Ανταλλάξτε το token με ένα βραχύβιο, κομμένο για τον συγκεκριμένο MCP server, με επιβεβλημένη επικύρωση audience. Η απαίτηση της προδιαγραφής για resource indicator κατά το RFC 8707 υπάρχει ακριβώς για να αποτυγχάνει το ξέπλυμα γενικών tokens.
  • Ταυτότητα μηχανής για μη επιτηρούμενα workloads: SEP-1046 client credentials, προτιμήστε private_key_jwt, ένας καταχωρισμένος client ανά workload agent, όχι ένας κοινός client «agents» για όλη την πλατφόρμα. Η ακτίνα έκρηξης ακολουθεί τη λεπτομέρεια της καταχώρισης.
  • Διπλή ταυτότητα για το ενδιαφέρον ενδιάμεσο: ένας agent που ενεργεί για λογαριασμό χρήστη αλλά τρέχει χωρίς επιτήρηση. Το token πρέπει να αναπαριστά και τον actor (τον agent) και τον subject (τον χρήστη), κάτι που το token exchange υποστηρίζει και οι περισσότεροι authorization servers πλέον εκφράζουν. Αυτό είναι το μοτίβο που κρατά απαντήσιμη σε έναν έλεγχο την ερώτηση «ποιος άνθρωπος λογοδοτεί για αυτή την ενέργεια», που είναι η ερώτηση που θα κάνει πράγματι η ομάδα συμμόρφωσής σας.

Για την ίδια την καταχώριση: το SEP-991 έκανε τα OAuth Client ID Metadata Documents το προτιμώμενο μοτίβο για clients και servers χωρίς προϋπάρχουσα σχέση, με ένα HTTPS URL ως αναγνωριστικό client. Κομψό για το ανοιχτό οικοσύστημα. Για μια κλειστή επιχείρηση, η προ-καταχώριση μέσω της εταιρικής πλατφόρμας ταυτότητας παραμένει η ισχυρότερη προεπιλογή, γιατί σας δίνει ιδιοκτησία, allow-listing και έλεγχο κύκλου ζωής, και αφαιρεί από το threat model σας μια ολόκληρη κατηγορία ανησυχιών SSRF από metadata fetch.

Το SEP-1046 είναι μία λωρίδα, όχι όλος ο δρόμος

Μία ώρα στο label auth του αποθετηρίου της προδιαγραφής αρκεί για να καταρρεύσει η αφήγηση του ενός SEP: υπάρχει μόνιμη ομάδα εργασίας για το auth με τακτικές συναντήσεις, και μια ουρά προτάσεων που σκιαγραφεί το επόμενο βήμα της εταιρικής εξουσιοδότησης MCP. Το SEP-1488 προσθέτει securitySchemes στα μεταδεδομένα των εργαλείων για διακομιστές μικτού auth, ένας διακομιστής με δημόσια εργαλεία δίπλα σε εργαλεία πίσω από OAuth. Το SEP-1489 τυποποιεί το σφάλμα με το οποίο ένα εργαλείο πυροδοτεί ροή OAuth στη μέση μιας συνεδρίας, δηλαδή step-up εξουσιοδότηση με όρους agents. Το SEP-2742 ζητά οι απομακρυσμένοι διακομιστές να δηλώνουν εκ των προτέρων τις μεθόδους αυθεντικοποίησής τους, ώστε ο client να ξέρει πού μπαίνει πριν συνδεθεί. Η υπογραφή μηνυμάτων HTTP επέστρεψε ως PR #2752 αφού το SEP-1415 έμεινε ανενεργό. Και η θωράκιση συνεχίζει να προστίθεται ανάμεσα στα μεγάλα SEP: υποχρεωτική επικύρωση issuer κατά RFC 9207 απέναντι σε επιθέσεις mix-up (#1721), Rich Authorization Requests κατά RFC 9396 (#1670), προώθηση refresh tokens για offline πρόσβαση (#1735), και μια ανοιχτή προσπάθεια να αδυνατίσει η προδιαγραφή εξουσιοδότησης αναθέτοντας στα RFC του OAuth πάνω στα οποία χτίζει (#3054). Αν η ασφάλεια των agents στην εταιρεία είναι δική σας ευθύνη, αυτή η ουρά issues είναι ο οδικός σας χάρτης. Διαβάστε την όπως διαβάζετε το δικό σας backlog.

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

Συγκεκριμένα, για μια ομάδα platform ή ασφάλειας που αναπτύσσει MCP μέσα σε έναν οργανισμό:

  • Καταγράψτε κάθε ενσωμάτωση MCP και ταξινομήστε την: διαδραστική, μη επιτηρούμενη ή acting-on-behalf-of. Η ροή ακολουθεί την κατηγορία, ποτέ το αντίστροφο.
  • Δώστε σε κάθε μη επιτηρούμενο agent δικό του καταχωρισμένο client στον identity provider σας. Ξεκινήστε με client secrets αν το απαιτεί το tooling σας, αλλά βάλτε το private_key_jwt στο roadmap τώρα και ελέγξτε αν το SDK σας το υποστηρίζει ήδη. Τα TypeScript, Python και Ruby το κάνουν.
  • Επιβάλετε επικύρωση audience σε κάθε MCP server που λειτουργείτε. Ένα token κομμένο για έναν server πρέπει να αποτυγχάνει σε άλλον. Είναι ο φθηνότερος έλεγχος σε όλη τη στοίβα και ο πιο συχνά παραλειπόμενος.
  • Απαγορεύστε το token pass-through στο code review, όπως απαγορεύετε το SQL που χτίζεται με strings. Είναι το SQL injection της ταυτότητας των agents: βολικό, παντού, και λάθος.
  • Κρατήστε τα δικαιώματα των agents read-only από προεπιλογή και βάλτε πύλη ελέγχου σε κάθε διαδρομή που μεταβάλλει κατάσταση, την ίδια στάση που υποστήριξα στο επίπεδο υποδομής στο άρθρο για το gateway της σειράς Agents on Call. Η αυθεντικοποίηση σας λέει ποιος είναι ο agent. Δεν λέει τίποτα για το τι πρέπει να του επιτρέπεται να κάνει.

Το ευρύτερο σημείο: κάθε μήνα, ακόμα ένα κομμάτι του «οι επιχειρήσεις δεν μπορούν να υιοθετήσουν agents επειδή Χ» λύνεται αθόρυβα σε κάποιο GitHub issue. Το auth ήταν το μεγαλύτερο Χ. Πριν από έναν χρόνο, η ειλικρινής απάντηση στο «πώς αυθεντικοποιούνται οι μη επιτηρούμενοι agents μας στους MCP servers» ήταν ένα σήκωμα των ώμων. Τώρα είναι ένας αριθμός SEP, δύο μέθοδοι αυθεντικοποίησης client και conformance tests σε τρία SDK. Όλοι μαθαίνουμε τι μπορούμε να χτίσουμε, και πώς, λίγο περισσότερο κάθε εβδομάδα. Οι ομάδες που παρακολουθούν αυτές τις ραφές καθώς κλείνουν θα παραδίδουν έναν χρόνο μπροστά από τις ομάδες που περιμένουν ένα τελειωμένο εγχειρίδιο, γιατί τέτοιο δεν θα υπάρξει.

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

Η ταυτότητα είναι μόνο το μισό της ασφάλειας των agents. Το IAM for LLM Apps: Least Privilege When the Caller Is a Model καλύπτει το άλλο μισό, την εξουσιοδότηση, στο AWS. Στο αδελφό site, το Agent Toolkit for AWS: The Docs Have a New Reader εξετάζει τι συμβαίνει όταν ο agent που καταναλώνει την υποδομή σας είναι και αυτός που διαβάζει το εγχειρίδιο, και το ercanermis.com έχει τον πλήρη χάρτη του τι γράφω και πού.

Αναφορές