MCP server security για AI agents: OAuth, scopes και ασφαλή εργαλεία
Το Model Context Protocol επιτρέπει σε AI clients και agents να ανακαλύπτουν εργαλεία, πόρους και prompts από εξωτερικούς servers. Αυτό απλοποιεί integrations με CRM, βάσεις γνώσης, αρχεία και επιχειρησιακά APIs. Ταυτόχρονα, ένα MCP tool μπορεί να διαβάζει ευαίσθητα δεδομένα ή να εκτελεί ενέργειες. Η σύνδεση δεν είναι ασφαλής μόνο επειδή χρησιμοποιεί ένα τυποποιημένο protocol.
Η ασφάλεια χρειάζεται σωστή ταυτότητα χρήστη και client, περιορισμένα scopes, validation tokens, authorization μέσα στο tool και ξεκάθαρο έλεγχο πριν από side effects. Το MCP είναι το κανάλι. Η εφαρμογή παραμένει υπεύθυνη για το ποιος μπορεί να κάνει τι.
Authentication και authorization είναι διαφορετικά
Το authentication απαντά ποιος είναι ο caller. Το authorization αποφασίζει αν επιτρέπεται να διαβάσει έναν συγκεκριμένο λογαριασμό ή να καλέσει ένα συγκεκριμένο tool. Ένα έγκυρο access token δεν δίνει αυτόματα πρόσβαση σε όλα τα δεδομένα.
Η επίσημη τεκμηρίωση του MCP TypeScript SDK περιγράφει τον MCP server ως OAuth resource server: επαληθεύει tokens που εξέδωσε authorization server και δεν εκδίδει ο ίδιος αυθαίρετα credentials. Ελλιπές ή ληγμένο token οδηγεί σε 401, ενώ έγκυρο token χωρίς απαιτούμενο scope οδηγεί σε 403.
Αυτός ο διαχωρισμός είναι σημαντικός για σωστό client behavior. Το 401 μπορεί να ξεκινήσει authentication flow. Το 403 σημαίνει ότι ο caller αναγνωρίστηκε αλλά δεν έχει το δικαίωμα.
OAuth discovery και audience validation
Ένας remote MCP server δημοσιεύει metadata ώστε ο client να ανακαλύψει ποιος authorization server προστατεύει τον πόρο και πώς αποκτά token. Η ροή πρέπει να ακολουθεί την τρέχουσα MCP specification και τα σχετικά OAuth standards, όχι custom redirect και ανταλλαγή API keys.
Ο server επαληθεύει signature, issuer, audience ή resource, expiry και scopes. Το audience check είναι κρίσιμο: token που εκδόθηκε για άλλη υπηρεσία δεν πρέπει να γίνεται δεκτό από τον MCP server. Η επίσημη τεκμηρίωση τονίζει ότι τα tokens πρέπει να έχουν εκδοθεί ειδικά για τον συγκεκριμένο protected resource.
Τα signing keys λαμβάνονται από το JWKS endpoint του identity provider και γίνονται cache με σωστό rotation. Ο server δεν εμπιστεύεται claims πριν ολοκληρωθεί η κρυπτογραφική επαλήθευση.
Per-server και per-tool authorization
Αν όλα τα tools είναι ευαίσθητα, η απλούστερη επιλογή είναι authentication για ολόκληρο το MCP endpoint. Κάθε request απαιτεί token. Αν ο server περιέχει δημόσια και προστατευμένα εργαλεία, μπορεί να εφαρμοστεί step-up authorization για τα συγκεκριμένα protected tools.
Η επίσημη τεκμηρίωση MCP Apps περιγράφει και τα δύο μοντέλα. Στο per-tool flow, μια προστατευμένη κλήση χωρίς token απαντά σε επίπεδο HTTP με 401 και WWW-Authenticate, ώστε ο host να ξεκινήσει OAuth. Δεν επιστρέφεται απλώς ένα tool error μέσα σε επιτυχημένο HTTP response.
Η per-tool προσέγγιση χρειάζεται ιδιαίτερη προσοχή στα JSON-RPC batches και στη συντήρηση της λίστας protected tools. Αν έστω μία κλήση στο batch απαιτεί authentication, η πολιτική πρέπει να είναι σαφής και να μην αφήνει bypass μέσω διαφορετικού message shape.
Scopes και least privilege
Ένα γενικό scope mcp μπορεί να προστατεύει την είσοδο, αλλά συνήθως δεν αρκεί για επιχειρησιακή εφαρμογή. Χρειάζονται πιο συγκεκριμένα scopes, όπως crm.read, crm.write, tickets.create ή payments.refund.
Ο client ζητά μόνο όσα χρειάζεται. Ένας knowledge assistant που διαβάζει policies δεν χρειάζεται write access στο CRM. Ένα tool που δημιουργεί draft προσφορά δεν χρειάζεται δικαίωμα να την εγκρίνει. Αυτό μειώνει το blast radius από λάθος prompt, compromised client ή κακή tool επιλογή.
Τα scopes δεν αντικαθιστούν τον έλεγχο object-level permissions. Το crm.read επιτρέπει κατηγορία πράξης, αλλά ο server πρέπει να ελέγξει αν ο συγκεκριμένος user δικαιούται το account ID που ζήτησε.
Tenant isolation και user context
Σε multi-tenant σύστημα, ο tenant δεν πρέπει να έρχεται ως ελεύθερο argument που το model μπορεί να αλλάξει. Προκύπτει από verified identity ή trusted server-side mapping. Κάθε database query φιλτράρεται με tenant scope ανεξάρτητα από τα arguments του tool.
Το ίδιο ισχύει για user permissions. Ο MCP handler λαμβάνει verified auth context και δημιουργεί services ή queries δεμένα σε αυτό. Δεν χρησιμοποιεί shared admin credential για όλους και μετά βασίζεται στο model να ζητήσει μόνο τα σωστά δεδομένα.
Η επίσημη SDK τεκμηρίωση δείχνει ότι το verified AuthInfo περνά στον handler. Ακόμη κι αν υπάρχει middleware στο HTTP boundary, το tool handler πρέπει να κάνει defence-in-depth authorization πριν διαβάσει ή αλλάξει δεδομένα.
Tool schemas δεν είναι μηχανισμός ασφάλειας
Το input schema ελέγχει μορφή και τύπους, όχι δικαιώματα ή επιχειρησιακή εγκυρότητα. Ένα accountId μπορεί να είναι έγκυρο string αλλά να ανήκει σε άλλον tenant. Ένα ποσό refund μπορεί να είναι αριθμός αλλά να ξεπερνά την αρχική πληρωμή.
Κάθε tool χρειάζεται server-side validation, ownership checks, business rules και ασφαλή errors. Τα error messages δεν πρέπει να αποκαλύπτουν αν υπάρχει ιδιωτικό resource που ο caller δεν μπορεί να δει.
Τα tool descriptions επίσης θεωρούνται μέρος της επιφάνειας αλληλεπίδρασης με το model, όχι policy enforcement. Ακόμη και αν περιγράφουν «χρησιμοποίησέ το μόνο μετά από έγκριση», ο server πρέπει να απαιτεί πραγματικό approval token ή state.
Επικίνδυνες και μη αναστρέψιμες ενέργειες
Tools που στέλνουν email, διαγράφουν δεδομένα, κάνουν refund ή αλλάζουν permissions χρειάζονται αυστηρότερο flow. Το agent μπορεί πρώτα να δημιουργεί preview ή draft και ο άνθρωπος να επιβεβαιώνει συγκεκριμένη ενέργεια με ποσό, παραλήπτη και συνέπειες.
Η έγκριση πρέπει να δεσμεύεται στο ακριβές payload. Αν μετά αλλάξει ο παραλήπτης ή το ποσό, η προηγούμενη έγκριση δεν ισχύει. Για υψηλό ρίσκο μπορεί να απαιτείται step-up authentication ή ισχυρότερο scope.
Οι side effects χρειάζονται idempotency key, audit log και δυνατότητα reconciliation. Αν ο client επαναλάβει κλήση μετά από timeout, δεν πρέπει να δημιουργηθεί δεύτερο ticket ή refund.
Token handling και μυστικά
Τα access tokens δεν πρέπει να περνούν στο model context, σε tool output ή σε logs. Ο MCP host και ο transport layer τα χειρίζονται ως credentials. Τα refresh tokens αποθηκεύονται κρυπτογραφημένα και δεν διανέμονται σε components που δεν τα χρειάζονται.
Ο server δεν πρέπει να δέχεται token forwarding προς downstream υπηρεσία αν το token δεν προορίζεται για εκείνη. Όταν χρειάζεται downstream access, χρησιμοποιείται κατάλληλο token exchange ή server-side credential με σαφή delegation, σύμφωνα με την αρχιτεκτονική identity.
Τα logs κρατούν request ID, tool name, caller subject, scopes, αποτέλεσμα και διάρκεια, αλλά όχι ολόκληρα tokens ή ευαίσθητα arguments.
Tool discovery και trusted registry
Η δυνατότητα να συνδεθεί ένας client σε οποιοδήποτε MCP server αυξάνει το supply-chain risk. Η επιχείρηση χρειάζεται allowlist ή ιδιωτικό registry με εγκεκριμένους servers, owners και versions. Πριν από εγκατάσταση εξετάζονται source, hosting, permissions και data flows.
Αλλαγές στα tools ή στα scopes χρειάζονται review. Ένας server που αρχικά είχε read-only tools μπορεί σε νέα έκδοση να προσθέσει destructive action. Ο client δεν πρέπει να θεωρεί ότι η προηγούμενη εμπιστοσύνη καλύπτει αυτόματα κάθε νέα δυνατότητα.
Observability και incident response
Κάθε tool call χρειάζεται trace που συνδέει user action, model decision, MCP request και downstream side effect. Έτσι η ομάδα μπορεί να απαντήσει ποιος κάλεσε τι, με ποιο scope και σε ποιο resource.
Alerts μπορούν να εντοπίζουν επαναλαμβανόμενα 401/403, απότομη αύξηση destructive calls, ασυνήθιστη πρόσβαση σε tenants και χρήση deprecated client version. Πρέπει επίσης να υπάρχει τρόπος άμεσης ανάκλησης tokens, απενεργοποίησης tool ή αποσύνδεσης server.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry αντιμετωπίζουμε κάθε MCP integration ως κανονική επιφάνεια API με πραγματικές επιχειρησιακές συνέπειες. Σχεδιάζουμε OAuth flows, resource και audience validation, scopes και tenant isolation πριν εκθέσουμε tools στον agent. Κάθε handler εφαρμόζει authorization και business rules στον server, ανεξάρτητα από τις οδηγίες του prompt.
Στις agentic AI λύσεις μας, διαχωρίζουμε read-only, reversible και destructive tools, προσθέτουμε δεσμευμένες approvals όπου χρειάζεται και χρησιμοποιούμε idempotency για side effects. Καταγράφουμε ασφαλή audit events και traces χωρίς tokens ή περιττά προσωπικά δεδομένα. Επιπλέον, οργανώνουμε allowlists και version review για MCP servers, ώστε μια νέα integration να μην αποκτά σιωπηλά περισσότερα δικαιώματα.
Checklist ασφαλούς MCP server
- Επαληθεύονται signature, issuer, audience, expiry και scopes;
- Επιστρέφονται σωστά 401 και 403 με OAuth metadata;
- Είναι τα scopes συγκεκριμένα και ελάχιστα;
- Προκύπτουν tenant και user context από verified identity;
- Κάνει κάθε tool object-level authorization;
- Δεσμεύεται η ανθρώπινη έγκριση στο ακριβές payload;
- Είναι idempotent οι κλήσεις με side effects;
- Αποκλείονται tokens και μυστικά από model context και logs;
- Υπάρχει allowlist, version review και kill switch;
Το MCP μειώνει το κόστος των integrations, όχι την ανάγκη για security design. Όταν identity, permissions και side effects ελέγχονται στον server, ο agent μπορεί να χρησιμοποιεί ισχυρά εργαλεία χωρίς να αποκτά περισσότερη εξουσία από τον άνθρωπο που εκπροσωπεί.