Οι Πύλες MCP Δεν Αρκούν: Οι AI agents Τεχνητής Νοημοσύνης Χρειάζονται Ταυτότητα, Εξουσιοδότηση Και Αποδεικτικά Στοιχεία

Οι πύλες MCP βρίσκονται παντού (και αυτό είναι καλό)

Το Model Context Protocol (MCP) έχει καταστεί πλέον ο προεπιλεγμένος τρόπος με τον οποίο οι AI agents επικοινωνούν με τον έξω κόσμο: το κοινό πρωτόκολλο για τη σύνδεση ενός πράκτορα με βάσεις δεδομένων, πλατφόρμες SaaS, περιβάλλοντα εκτέλεσης κώδικα, συστήματα πληρωμών και εσωτερικές υπηρεσίες. Εάν οι πράκτορές σας κάνουν κάτι χρήσιμο, είναι σχεδόν βέβαιο ότι το καταφέρνουν μέσω του MCP.

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

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

Εάν η επιχείρησή σας βρίσκεται στο στάδιο όπου μεταφέρει τους ΑΙ agents από το περιβάλλον των δοκιμών στην κανονική παραγωγή, εκεί δηλαδή όπου καλούν πραγματικά API, εκτελούν κώδικα, αναζητούν ευαίσθητα δεδομένα και αλληλεπιδρούν με άλλους AI agents εκ μέρους της επιχείρησής σας, η δρομολόγηση και ο έλεγχος πρόσβασης είναι μεν απαραίτητα, αλλά σε καμία περίπτωση δεν αρκούν. Τα πραγματικά δύσκολα προβλήματα ασφάλειας είναι η ταυτότητα, η εξουσιοδότηση και τα αποδεικτικά στοιχεία. Και οι πύλες MCP δεν επιλύουν κανένα από αυτά.

Τα Τρία Κενά Που Αφήνουν Ανοιχτά Οι Πύλες MCP

Οι εταιρικές υλοποιήσεις AI agents πρέπει να δώσουν σαφείς απαντήσεις σε τρία βασικά ερωτήματα πριν μπορέσουν να περάσουν στην παραγωγή. Οι πύλες MCP αφήνουν και τα τρία αναπάντητα.

Κενό 1: Ταυτότητα. «Ποιος Είναι Αυτός Ο AI agent;»

Οι πύλες MCP πραγματοποιούν έλεγχο ταυτότητας σε επίπεδο σύνδεσης. Όταν φτάνει ένα αίτημα με έγκυρο API key ή OAuth token, η πύλη το συγκρίνει με μια λίστα και το αίτημα εγκρίνεται. Αυτό σας ενημερώνει ότι το διαπιστευτήριο είναι έγκυρο. Δεν σας λέει όμως ποιος καλεί.

Στην πράξη, οι περισσότεροι AI agents λειτουργούν με API keys που είναι ενσωματωμένα στον κώδικά τους ή με κοινόχρηστα token ενός γενικού λογαριασμού υπηρεσίας. Αν ο AI agent Α και ο AI agent Β χρησιμοποιούν και οι δύο τα ίδια διαπιστευτήρια υπηρεσίας για να επικοινωνήσουν με έναν διακομιστή MCP, η πύλη βλέπει δύο πανομοιότυπους καλούντες. Δεν υπάρχει μηχανισμός για τον πράκτορα να αποδείξει κρυπτογραφικά την ταυτότητά του, ούτε διαβεβαίωση που να υποστηρίζεται από πιστοποιητικό και να μπορεί να επαληθευτεί ανεξάρτητα από μια κατάντη υπηρεσία.

Αυτό είναι ένα πρόβλημα που ο κόσμος των μικροϋπηρεσιών έλυσε πριν από χρόνια με τα SPIFFE και mTLS. Κάθε υπηρεσία αποκτά μια μοναδική, κρυπτογραφικά επαληθεύσιμη ταυτότητα. Όταν η Υπηρεσία Α καλεί την Υπηρεσία Β, η υπηρεσία που λαμβάνει την κλήση γνωρίζει ακριβώς ποιος καλεί και μπορεί να το αποδείξει. Αντίθετα, οι AI agents που αναπτύσσονται με τα σημερινά πλαίσια δεν διαθέτουν τίποτα από όλα αυτά. Λειτουργούν σε ένα κενό ταυτότητας, και οι υπάρχουσες πύλες MCP δεν κάνουν τίποτα για να το αλλάξουν αυτό.

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

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

Ένα διακριτικό. Πιθανώς κοινό για πολλούς AI agents. Πιθανώς μακράς διάρκειας. Χωρίς πληροφορίες σχετικά με το ποιο workload το παρήγαγε, σε ποιο πλαίσιο λειτουργούσε ή αν έχει αντικατασταθεί από νεότερη έκδοση. Ο server του εργαλείου απλά το αποδέχεται ή το απορρίπτει. Αυτή είναι όλη κι όλη η ιστορία της ταυτοποίησης εδώ.

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

spiffe://diagrid.io/ns/payments/fraud-detection-agent

Αυτό το URI δεν είναι μυστικό. Δεν χρειάζεται να είναι. Είναι μια επαληθεύσιμη δήλωση που εκδίδεται από την πλατφόρμα, συνδεδεμένη με το συγκεκριμένο workload που εκτελείται σε ένα συγκεκριμένο namespace σε έναν συγκεκριμένο trust domain, περιστρέφεται αυτόματα και μπορεί να αποδειχθεί από οποιαδήποτε υπηρεσία που εμπιστεύεται τον ίδιο trust domain. Ο server του εργαλείου λήψης δεν ελέγχει απλώς αν «βρίσκεται αυτό το διαπιστευτήριο στη λίστα επιτρεπόμενων;». Επαληθεύει: ποιο είναι αυτό το συγκεκριμένο workload, πού εκτελείται και αν πράγματι είναι το workload που υποτίθεται ότι πρέπει να πραγματοποιεί αυτήν την κλήση;

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

Από την άποψη των προτύπων, η χρήση του SPIFFE για την ταυτότητα των workloads βρίσκεται υπό ενεργή συζήτηση στην ομάδα εργασίας IETF WIMSE και στην ομάδα εργασίας AAIF Identity & Trust.

Για μια πιο εμπεριστατωμένη ανάλυση της ταυτότητας, διαβάστε το άρθρο «Agent Identity: The Foundational Layer that AI Is Still Missing» (Ταυτότητα Πράκτορα: Το Θεμελιώδες Επίπεδο Που Εξακολουθεί Να Λείπει Από Την Τεχνητή Νοημοσύνη).

Κενό 2: Εξουσιοδότηση Πέρα Από Τη Δρομολόγηση. «Τι Επιτρέπεται Να Κάνει Αυτός ο AI agent;»

Σκεφτείτε έναν πράκτορα με πρόσβαση σε έναν διακομιστή MCP βάσης δεδομένων πελατών. Η πύλη επιτρέπει τη σύνδεση, ο AI agent διαθέτει έγκυρα διαπιστευτήρια και ο κανόνας δρομολόγησης εγκρίνει το αίτημα. Ο AI agent βρίσκεται στη μέση ��ης ροής εργασίας όταν το LLM, παρερμηνεύοντας μια ασαφή οδηγία, δημιουργεί μια κλήση για τη διαγραφή εγγραφών βάσει ενός γενικού φίλτρου. Τίποτα στην πύλη δεν μπορεί να το σταματήσει αυτό. Ο κανόνας δρομολόγησης όριζε ότι ο AI agent μπορούσε να έχει πρόσβαση στον διακομιστή. Δεν ανέφερε τίποτα σχετικά με το τι μπορούσε να κάνει ο AI agent αφού έφτανε εκεί.

Αυτό είναι το κενό εξουσιοδότησης που αφήνουν ανοιχτό οι πύλες MCP. Ελέγχουν την πρόσβαση: ποιοι καλούντες μπορούν να φτάσουν σε ποιους διακομιστές. Δεν ελέγχουν τη συμπεριφορά: ποιες ενέργειες επιτρέπεται να εκτελέσει μια συγκεκριμένη ταυτότητα πράκτορα, σε ποια πλαίσια ροής εργασίας, υπό ποιες συνθήκες. Για το ντετερμινιστικό λογισμικό, αυτή η διάκριση δεν έχει σχεδόν καμία σημασία· μπορείτε να αναλύσετε εκ των προτέρων το γράφημα κλήσεων. Για τους AI agents, των οποίων η συμπεριφορά είναι αναδυόμενη και εξ' ορισμού μη ντετερμινιστική, είναι η διαφορά μεταξύ ενός μοντέλου ασφάλειας και μιας ψευδαίσθησης μοντέλου ασφάλειας.

Αυτό που απαιτείται σε περιβάλλον παραγωγής είναι η εξουσιοδότηση «deny-by-default» σε επίπεδο ροής εργασίας: δηλωτικές πολιτικές που καθορίζουν με ακρίβεια ποιες ταυτότητες AI agents μπορούν να καλέσουν συγκεκριμένες ροές εργασίας και εργαλεία. Αυτές οι πολιτικές πρέπει να επιβάλλονται στο επίπεδο της πλατφόρμας ανεξάρτητα από το τι αποφασίζει να κάνει το LLM. Πρέπει να βρίσκονται στις ρυθμίσεις της υποδομής, να ανήκουν στις ομάδες πλατφόρμας και ασφάλειας, και να είναι ελέγξιμες. Όχι να είναι θαμμένες στον κώδικα της εφαρμογής, όπου μπορούν εύκολα να παραλειφθούν, να παρακαμφθούν ή απλά να ξεχαστούν.

Κενό 3: Απόδειξη. «Τι Έχει Κάνει Αυτός Ο AI agent και Πώς Μπορούμε Να Το Αποδείξουμε;»

Οι πύλες MCP δημιουργούν αρχεία καταγραφής. Τα αρχεία καταγραφής, αν και είναι χρήσιμα, δεν αποτελούν απόδειξη.

Οι εταιρικές υποδομές καταγραφής έχουν βελτιωθεί σημαντικά. Οι σύγχρονες πλατφόρμες SIEM μπορούν να κάνουν τις ροές καταγραφής ανθεκτικές σε παραβιάσεις, ενώ με τα κατάλληλα εργαλεία η δημιουργία αμετάβλητων διαδρομών ελέγχου είναι πλέον εφικτή. Ωστόσο, ακόμη και ένα τέλεια διατηρημένο αρχείο καταγραφής εστιάζει σε λάθος βάση. Όταν μια ομάδα συμμόρφωσης ρωτά «μπορείτε να αποδείξετε ότι ένας άνθρωπος ενέκρινε αυτή την κλήση εργαλείου πριν την εκτελέσει ο AI agent;», μια απλή εγγραφή που αναφέρει: εργαλείο: transfer_funds, κατάσταση: εγκρίθηκε, χρήστης: alice δεν αποτελεί ουσιαστική απάντηση. Δεν παρέχει καμία κρυπτογραφική εγγύηση ότι τα καταγεγραμμένα συμβάντα συνέβησαν πράγματι με τη σειρά που εμφανίζονται.

Σε συστήματα πολλαπλών AI agents, αυτό το πρόβλημα επιδεινώνεται. Όταν ο AI agent Γ καλεί ένα εργαλείο με καταστροφικές συνέπειες, είχε όντως εξουσιοδοτηθεί από τον πράκτορα B, ο οποίος με τη σειρά του είχε λάβει εξουσιοδότηση από τον πράκτορα A, ο οποίος με τη σειρά του ενεργοποιήθηκε από έναν άνθρωπο; Χωρίς μια υπογεγραμμένη αλυσίδα επιτήρησης που να μεταδίδεται σε κάθε όριο μεταξύ των AI agents, δεν υπάρχει τρόπος να ανακατασκευαστεί ή να επαληθευτεί η αλυσίδα λήψης αποφάσεων.

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

{
  "step": "fraud_check_passed",
  "agent": "spiffe://diagrid.io/ns/payments/sa/fraud-detection-agent",
  "timestamp": "2025-04-18T14:23:11Z",
  "result": "approved",
  "signature": "eyJhbGciOiJFUzI1NiJ9..."
}

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

Ο νόμος της ΕΕ για την Τεχνητή Νοημοσύνη, οι νέες οδηγίες της SEC και οι εξελισσόμενες απαιτήσεις του SOC2 συγκλίνουν όλες σε μια σαφή προσδοκία: οι επιχειρήσεις πρέπει να επιδεικνύουν επαληθεύσιμο έλεγχο και λογοδοσία για τα συστήματα Τεχνητής Νοημοσύνης.

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

Πώς Μοιάζει Μια Υποδομή Έτοιμη Για Τεχνητή Νοημοσύνη

Η κάλυψη των τριών κενών απαιτεί τρεις δυνατότητες που λειτουργούν στο επίπεδο της πλατφόρμας ΑΙ, κάτω από τον κώδικα του πράκτορα ή της εφαρμογής και πάνω από το επίπεδο του δικτύου και της υπολογιστικής ισχύος.

Κρυπτογραφική Ταυτότητα Πράκτορα

Κάθε AI agents χρειάζεται μια κρυπτογραφική ταυτότητα βασισμένη στο SPIFFE, ένα πιστοποιητικό που εκδίδεται και ανανεώνεται αυτόματα από την πλατφόρμα. Όταν ένας AI agents καλεί ένα εργαλείο ή έναν άλλο πράκτορα, η υπηρεσία που λαμβάνει την κλήση επαληθεύει την ταυτότητα μέσω του τυπικού mTLS. Δεν πρόκειται για ένα απλό token σε μια κεφαλίδα. Είναι μια διασφάλιση που υποστηρίζεται από πιστοποιητικό και βασίζεται σε μια αλυσίδα εμπιστοσύνης την οποία ο οποιοσδήποτε συμμετέχων μπορεί να επαληθεύσει αυτόνομα. Πρόκειται για την ίδια δοκιμασμένη στην πράξη προσέγγιση που ασφαλίζει την επικοινωνία μεταξύ μικροϋπηρεσιών, η οποία τώρα επεκτείνεται στις μοναδικές προκλήσεις των μη ντετερμινιστικών, αυτόνομων AI agents.

Εξουσιοδότηση Ροής Εργασιών Zero-Trust

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

Αυτή είναι η διαφορά μεταξύ του «αυτός ο AI agent μπορεί να φτάσει σε αυτόν τον διακομιστή» (αυτό που κάνουν οι πύλες) και του «αυτή η συγκεκριμένη ταυτότητα πράκτορα μπορεί να ενεργοποιήσει αυτή τη συγκεκριμένη ροή εργασίας σε αυτόν τον συγκεκριμένο στόχο, και τίποτα άλλο» (αυτό που απαιτείται σε περιβάλλον παραγωγής).

Πολιτική ως Κώδικας Πάνω σε Υπογεγραμμένο Ιστορικό

Οι γενικοί κανόνες συσχέτισης ταυτότητας και ροής εργασιών είναι απαραίτητοι αλλά δεν αρκούν. Τα ουσιαστικά ερωτήματα εξουσιοδότησης εξαρτώνται από το εκάστοτε πλαίσιο και είναι συγκυριακά: προηγήθηκε αυτής της κλήσης εργαλείου κάποιο βήμα ανίχνευσης απάτης; Εγκρίθηκε από άνθρωπο η κλήση τα τελευταία 30 δευτερόλεπτα; Ο AI agent που πραγματοποιεί αυτή την κλήση είναι ο ίδιος που έλαβε το αρχικό αίτημα του χρήστη ή μήπως έχει παραβιαστεί η αλυσίδα;

Αυτά τα ερωτήματα δεν μπορούν να απαντηθούν μόνο από το εκάστοτε αίτημα. Απαιτούν συλλογιστική σχετικά με το ιστορικό της ροής εργασίας που οδήγησε στην κλήση. Με ένα κρυπτογραφικά υπογεγραμμένο ιστορικό εκτέλεσης που μεταδίδεται σε κάθε βήμα, ένας μηχανισμός πολιτικής τύπου Open Policy Agent (OPA) μπορεί να αξιολογήσει το Rego (ή οποιαδήποτε άλλη γλώσσα πολιτικής) σε σχέση με ολόκληρη την αλυσίδα τη στιγμή της λήψης της απόφασης:

allow_tool_call {
  input.history[_].step == "human_approval"
  input.history[_].step == "fraud_check_passed"
  input.history[_].agent == input.calling_agent
}

Η πολιτική αξιολογείται από την πλευρά του παραλήπτη και όχι του καλούντος. Οι AI agents δεν μπορούν να παραποιήσουν το ιστορικό, καθώς κάθε καταχώριση υπογράφεται από την ταυτότητα που την δημιούργησε. Αυτό μετατρέπει το ίδιο το ιστορικό της ροής εργασιών σε μια επαληθεύσιμη εισαγωγή δ��δομένων για την εξουσιοδότηση, με τον ίδιο τρόπο που το OPA αξιολογεί ήδη τις αξιώσεις JWT και το πλαίσιο αιτημάτων για τα API HTTP, αλλά τώρα επεκτείνεται από άκρο σε άκρο σε αλυσίδες εκτέλεσης πολλαπλών AI agents και εργαλείων.

Κρυπτογραφική Αλυσίδα Επιτήρησης

Όταν οι AI agents συνεργάζονται ξεπερνώντας τα όρια των υπηρεσιών, κάθε βήμα πρέπει να υπογράφεται. Κάθε υπηρεσία υπογράφει το συσσωρευμένο ιστορικό εκτέλεσης με το δικό της πιστοποιητικό ταυτότητας, δημιουργώντας μια αλυσίδα που αποτρέπει την παραποίηση. Ένα εργαλείο κατάντη δεν ελέγχει απλώς αν «έχει άδεια αυτός που καλεί;». Επαληθεύει ολόκληρο το ιστορικό: ποιος ξεκίνησε τη ροή εργασίας, ποιες εγκρίσεις δόθηκαν, ποια βήματα επικύρωσης ολοκληρώθηκαν με επιτυχία και αν κάθε ταυτότητα στην αλυσίδα είναι εξουσιοδοτημένη.

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

Πώς Λειτουργεί Αυτό στην Πράξη

Δεν πρόκειται για θεωρητικές απαιτήσεις. Το Diagrid Catalyst, η διαχειριζόμενη πλατφόρμα για την εκτέλεση εφαρμογών βασισμένων στο Dapr και AI agents σε περιβάλλον παραγωγής, παρέχει όλες αυτές τις δυνατότητες σήμερα.

Το MCP ως υποδομή. Οι συνδέσεις διακομιστών MCP ορίζονται ως Kubernetes CRDs περιλαμβάνοντας τις λεπτομέρειες σύνδεσης, τα διαπιστευτήρια και τα πεδία πρόσβασης. Δεν υπάρχει σκληρά κωδικοποιημένη λογική σύνδεσης στον κώδικα της εφαρμογής. Τα διαπιστευτήρια επιλύονται από αποθηκευμένους κωδικούς κατά την εκτέλεση και δεν εκτίθενται ποτέ στον κώδικα του AI agent.

Ανθεκτικές κλήσεις εργαλείων MCP. Κάθε κλήση εργαλείου MCP εκτελείται ως ροή εργασίας μέσα στο Dapr sidecar. Εάν μια διαδικασία διακοπεί κατά τη διάρκεια της κλήσης, η εκτέλεση συνεχίζεται αυτόματα από το τελευταίο σημείο ελέγχου. Οι κλήσεις μεγάλης διάρκειας (μεταφορές βάσεων δεδομένων, εξωτερικές ακολουθίες API, εκτέλεση κώδικα) επιβιώνουν αυτόματα από τυχόν αποτυχίες διαδικασιών και κόμβων.

Hooks ενδιάμεσου λογισμικού. Πριν και μετά από κάθε κλήση εργαλείου, τα διαμορφώσιμα hooks ροής εργασίας επιτρέπουν την εξουσιοδότηση ανά εργαλείο, την καταγραφή ελέγχου, τον περιορισμό ρυθμού, την επικύρωση εισαγόμενων δεδομένων και τους ελέγχους κόστους, χωρίς τροποποίηση του κώδικα του πράκτορα. Αυτά τα hooks αποτελούν αυτόνομες ροές εργασίας, είναι συνθέσιμα, αναπτύσσονται ανεξάρτητα και αποτελούν το σημείο όπου συνδέετε το OPA ή οποιαδήποτε άλλη μηχανή πολιτικής για να αξιολογήσει το υπογεγραμμένο ιστορικό πριν από την εκτέλεση ενός εργαλείου.

Δηλωτικός έλεγχος πρόσβασης ροών εργασίας. Ένα Kubernetes CRD που ελέγχει ποιες ταυτότητες εφαρμογών μπορούν να ξεκινήσουν συγκεκριμένες ροές εργασίας και δραστηριότητες σε μια εφαρμογή-στόχο. Χρησιμοποιεί ταυτοποίηση βασισμένη σε SPIFFE/mTLS για την επαλήθευση του καλούντος. Υποστηρίζει φίλτρα glob, κανόνες ανά καλούντα και πολιτικές καθολικής απόρριψης σε επίπεδο namespace. Αν δεν υπάρχει ρητή έγκριση από κάποια πολιτική, κάθε ενέργεια απαγορεύεται αυτόματα.

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

Ανθρώπινη παρέμβαση με απόδειξη. Οι AI agents μπορούν να διακόπτουν τη ροή για λήψη ανθρώπινης έγκρισης, χρησιμοποιώντας μόνιμα συμβάντα. Όταν ένα κατάντη εργαλείο λαμβάνει το υπογεγραμμένο ιστορικό, μπορεί να επαληθεύσει κρυπτογραφικά ότι η έγκριση πρά��ματι έλαβε χώρα, και όχι απλώς ότι το αναφέρει ένα αρχείο καταγραφής.

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

Ο AI agent επιστροφής χρημάτων φτάνει το όριο των $10,000 
        │
        ▼
Η ροή εργασίας αναστέλλεται — εκπέμπει αίτημα έγκρισης
  — στέλνει μήνυμα Slack στο κανάλι payments-approvals
  — καταγράφει την εκκρεμή έγκριση στο υπογεγραμμένο ιστορικό
  — ορίζει χρονικό όριο 30 λεπτών
        │
   Ο άνθρωπος ελέγχει στο Slack
        │
        ├── Εγκρίνει → η ροή εργασίας συνεχίζεται
        │             το βήμα έγκρισης υπογράφεται και προστίθεται στο ιστορικό
        │
        └── Απόρριψη / λήξη χρόνου → η ροή εργασίας τερματίζεται
                              η απόρριψη καταγράφεται στο υπογεγραμμένο ιστορικό
        │
        ▼
Το εργαλείο επιστροφής χρημάτων λαμβάνει την κλήση
  — επαληθεύει ότι το υπογεγραμμένο ιστορικό περιέχει το βήμα human_approval
  — επιβεβαιώνει ότι η χρονική σήμανση έγκρισης είναι εντός του χρονικού πλαισίου της πολιτικής
  — επιβεβαιώνει ότι η ταυτότητα που εγκρίνει είναι εξουσιοδοτημένος εγκρίνων
  — εκτελείται μόνο εάν όλοι οι έλεγχοι επιτύχουν

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

Το Ερώτημα Που Θα Έπρεπε Να Θέτουν Οι Επιχειρήσεις

Το ερώτημα δεν είναι «Χρειαζόμαστε μια πύλη MCP;». Προφανώς και τη χρειάζεστε και θα πρέπει σίγουρα να αποτελεί μέρος της διαχείρισης των εισερχόμενων συνδέσεών σας. Το MCP είναι το πρωτόκολλο· αυτό που χρειάζεται η υποδομή για τη διαχείριση των συνδέσεων σε μεγάλης κλίμακας διακομιστές MCP, ώστε να εκτελείτε δρομολόγηση και να εφαρμόζετε περιορισμούς ρυθμού.

Το πραγματικό ερώτημα είναι: Παρέχει η υποδομή MCP που διαθέτετε ταυτότητα, εξουσιοδότηση και απόδειξη της γνησιότητας;

Μπορεί η πλατφόρμα σας ΑΙ να σας πει ποιος ακριβώς AI agents πραγματοποίησε μια κλήση; Όχι απλά ποια διαπιστευτήρια χρησιμοποιήθηκαν, αλλά ποια είναι η κρυπτογραφικά επαληθευμένη ταυτότητά του; Μπορεί να επιβάλει πολιτικές μηδενικής εμπιστοσύνης και αποκλεισμού βάσει προεπιλογής σχετικά με το τι επιτρέπεται να κάνει κάθε AI agents; Πολιτικές οι οποίες θα ελέγχονται από την ομάδα της πλατφόρμας σας και θα επιβάλλονται ανεξάρτητα από το τι αποφασίζει το LLM;

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

Εάν η απάντηση είναι όχι, τότε δεν διαθέτετε επίπεδο ασφάλειας για τους AI agents. Διαθέτετε απλώς έναν δρομολογητή.

Και οι δρομολογητές πλέον δεν αρκούν.

Εξερευνήστε το Catalyst πιο αναλυτικά.

Συζητήστε με έναν Ειδικό