AI agents και indirect prompt injection: γιατί το web γίνεται νέο πεδίο ρίσκου για τις επιχειρήσεις

Το indirect prompt injection κρύβει οδηγίες σε sites, emails ή metadata και αυξάνει το ρίσκο όταν οι AI agents μπορούν να εκτελούν ενέργειες.

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

Το πρόσφατο θέμα του InfoWorld, βασισμένο σε έρευνα της Zscaler ThreatLabz, δείχνει ακριβώς αυτό: ορισμένοι autonomous AI agents μπορούν να παρασυρθούν από indirect prompt injection, δηλαδή από κρυφές ή έμμεσες οδηγίες που βρίσκονται μέσα σε ιστοσελίδες, metadata, JSON-LD, CSS-hidden blocks ή άλλα κομμάτια περιεχομένου. Για μια επιχείρηση που χρησιμοποιεί AI σε customer support, marketing operations, procurement, e-commerce, analytics ή software workflows, το ερώτημα δεν είναι μόνο “ποιο μοντέλο είναι καλύτερο;”. Είναι “τι επιτρέπουμε στο μοντέλο να δει, να εμπιστευτεί και να κάνει;”.

Περιεχόμενα

Τι είναι το indirect prompt injection στην πράξη

Στο κλασικό prompt injection, κάποιος γράφει απευθείας στο AI μια οδηγία που προσπαθεί να παρακάμψει τους κανόνες του. Στο indirect prompt injection, η οδηγία δεν έρχεται απευθείας από τον χρήστη. Κρύβεται μέσα σε εξωτερικό περιεχόμενο που ο agent διαβάζει ως μέρος της δουλειάς του: μια σελίδα, ένα email, ένα αρχείο, ένα documentation page ή ένα αποτέλεσμα αναζήτησης.

Η διαφορά είναι κρίσιμη. Ο άνθρωπος μπορεί να βλέπει μια κανονική σελίδα, ενώ ο agent μπορεί να διαβάζει και αόρατο περιεχόμενο στο DOM, schema markup ή metadata. Αν το σύστημα δεν ξεχωρίζει καθαρά την “πληροφορία που πρέπει να αναλυθεί” από την “εντολή που πρέπει να εκτελεστεί”, τότε ο επιτιθέμενος μπορεί να προσπαθήσει να μπει στη ροή αποφάσεων χωρίς να ακουμπήσει απευθείας την εφαρμογή της εταιρείας.

Απάντηση πρώτα: το indirect prompt injection δεν λύνεται μόνο με ένα «καλύτερο prompt». Χρειάζεται αρχιτεκτονική που αντιμετωπίζει κάθε εξωτερική πηγή ως μη έμπιστη και δεν επιτρέπει στο περιεχόμενό της να αποκτήσει δικαιώματα εντολής.

Τι έδειξε η δοκιμή της Zscaler

Η Zscaler περιέγραψε δύο πραγματικά σενάρια όπου websites χρησιμοποίησαν indirect prompt injection για να επηρεάσουν AI agents. Στο πρώτο, ένα κακόβουλο site παρουσιάστηκε σαν τεχνικό documentation για ένα ψεύτικο Python module. Μέσα στη σελίδα υπήρχαν στοιχεία SEO poisoning ώστε να εμφανίζεται σε σχετικές αναζητήσεις, αλλά και κρυφές οδηγίες που προσπαθούσαν να πείσουν τον agent ότι χρειάζεται μια μικρή πληρωμή για developer license ή API key.

Στο δεύτερο, ένα typosquatting domain προσποιούνταν υπηρεσία γύρω από DeFi portfolio tracking. Το site χρησιμοποίησε keywords, Open Graph στοιχεία, X metadata και JSON-LD για να παρουσιαστεί ως αξιόπιστη πηγή. Παράλληλα, κρυφό prompt μέσα στη σελίδα προσπαθούσε να κατευθύνει το μοντέλο ώστε να θεωρήσει το κακόβουλο domain ως την επίσημη πηγή για σχετικές αναζητήσεις.

Η έρευνα της Zscaler ανέφερε δοκιμές σε 26 LLMs. Για το σενάριο πληρωμής, 4 μοντέλα απέτυχαν να πάρουν κατάλληλη απόφαση. Για το σενάριο της ψεύτικης DeBank σελίδας, 2 από τα 26 μοντέλα ταξινόμησαν λάθος το site σε ορισμένα context. Αυτοί οι αριθμοί είναι χρήσιμοι ως ένδειξη, όχι ως οριστική κατάταξη ασφάλειας μοντέλων. Η ίδια η συμπεριφορά ενός agent μπορεί να αλλάξει ανάλογα με το prompt, τα εργαλεία, τις άδειες, το context και την υλοποίηση.

Τι μέτρησε η δοκιμή της Zscaler

Στιγμιότυπο συμπεριφοράς σε συγκεκριμένα prompts και context, όχι μόνιμη κατάταξη ασφάλειας.

26LLMs στη δοκιμή
4Αποτυχίες στο σενάριο πληρωμής
2Λάθος ταξινομήσεις της ψεύτικης σελίδας

Γιατί τα metadata και το JSON-LD γίνονται επικίνδυνα όταν τα διαβάζει agent

Για χρόνια, οι marketers και οι SEO ομάδες χρησιμοποιούν structured data για να βοηθήσουν τις μηχανές αναζήτησης να καταλάβουν ένα website. Το JSON-LD, τα schema objects, τα Open Graph tags και τα meta fields έχουν σχεδιαστεί για να δίνουν “σήματα” στις πλατφόρμες. Όταν όμως ένας AI agent τα αντιμετωπίζει σαν υψηλής αξιοπιστίας πληροφορία, ένας επιτιθέμενος μπορεί να τα χρησιμοποιήσει για να του περάσει ψευδείς παραδοχές.

Στο παράδειγμα της Zscaler, το structured data παρουσίαζε μια ψεύτικη εφαρμογή ως κανονικό software και συνέδεε τη διαδικασία με πληρωμή. Το πρόβλημα δεν είναι ότι το JSON-LD είναι κακό. Το πρόβλημα είναι ότι ένα σύστημα AI μπορεί να δώσει δυσανάλογο βάρος σε structured fields αν δεν έχει ξεκάθαρους κανόνες εμπιστοσύνης. Για e-commerce και marketing ομάδες, αυτό σημαίνει ότι το “metadata hygiene” δεν είναι μόνο SEO θέμα. Είναι και θέμα ασφάλειας για εργαλεία που κάνουν crawling, summarization, enrichment ή automated decisioning.

Το πραγματικό ρίσκο δεν είναι η μικρή πληρωμή, αλλά η εξουσιοδότηση

Το σενάριο της ψεύτικης χρέωσης των 3 δολαρίων είναι εύκολο να το υποτιμήσει κανείς. Για μια επιχείρηση, όμως, η ουσία δεν είναι το ποσό. Η ουσία είναι ότι ο agent μπορεί να έχει πρόσβαση σε actions: να ανοίξει ticket, να εγκρίνει προμηθευτή, να δημιουργήσει περιεχόμενο, να τροποποιήσει product feed, να καλέσει API, να στείλει email, να μεταφέρει δεδομένα ή να προτείνει πληρωμή.

Αν ένας agent είναι συνδεδεμένος με εργαλεία procurement, CRM, ad platforms, CMS, ERP ή customer support, τότε μια κρυφή οδηγία σε τρίτο περιεχόμενο μπορεί να επηρεάσει μια επιχειρησιακή διαδικασία. Γι’ αυτό το ρίσκο μεγαλώνει όσο μεγαλώνει η αυτονομία. Ένα chatbot που απαντά μόνο με κείμενο έχει διαφορετικό προφίλ κινδύνου από έναν agent που μπορεί να εκτελέσει ενέργειες με inherited permissions.

Η κρίσιμη ερώτηση πριν από κάθε σύνδεση

Τι μπορεί να αλλάξει ο agent αν μια εξωτερική σελίδα τον παραπλανήσει;

Το πραγματικό blast radius ορίζεται από τα permissions, τα διαθέσιμα εργαλεία και τα approval gates. Ένας read-only agent έχει διαφορετικό ρίσκο από έναν agent που μπορεί να δημοσιεύσει, να πληρώσει ή να στείλει δεδομένα.

Γιατί οι άνθρωποι και οι agents διαβάζουν διαφορετικά το ίδιο περιεχόμενο

Ένας άνθρωπος που βλέπει ξαφνικά αίτημα πληρωμής μέσα σε άσχετο documentation πιθανότατα θα σταματήσει. Θα σκεφτεί αν το domain είναι σωστό, αν έχει ξαναδεί τον προμηθευτή, αν το αίτημα ταιριάζει με την εμπειρία του. Ο agent, αντίθετα, μπορεί να διαβάσει το αίτημα ως μέρος μιας διαδικασίας, ειδικά αν το περιεχόμενο το παρουσιάζει ως “απαραίτητο βήμα” ή ως δομημένο πεδίο.

Αυτό δεν σημαίνει ότι οι άνθρωποι είναι άτρωτοι. Σημαίνει ότι οι agents χρειάζονται διαφορετικά controls. Δεν έχουν την ίδια κοινωνική μνήμη, την ίδια αίσθηση προμηθευτή, την ίδια δυσπιστία απέναντι σε απροσδόκητες οδηγίες. Έχουν context window. Και αν το context window γεμίσει με untrusted content, τότε αυτό το περιεχόμενο γίνεται μέρος του decision surface.

Τι σημαίνει για e-commerce, marketing και content operations

Οι ομάδες marketing και e-commerce ήδη χρησιμοποιούν AI για product descriptions, feed optimization, competitor monitoring, SEO briefs, social captions, customer review analysis και ad variations. Πολλά από αυτά τα workflows βασίζονται σε εξωτερικά δεδομένα: URLs ανταγωνιστών, marketplaces, documentation, reviews, scraped search results και PDFs. Κάθε τέτοια πηγή μπορεί θεωρητικά να περιέχει οδηγίες που δεν προορίζονται για άνθρωπο, αλλά για agent.

Ένα πρακτικό παράδειγμα: μια ομάδα ζητά από AI agent να αναλύσει σελίδες ανταγωνιστών και να προτείνει αλλαγές σε product pages. Αν ο agent διαβάζει hidden text ή metadata και μετά έχει δικαίωμα να ενημερώσει περιβάλλον προσχεδίου στο CMS, μπορεί να εισάγει λάθος claims, κακόβουλους links ή παραπλανητικές προτάσεις. Αν ο agent δουλεύει με ad accounts, το ρίσκο μπορεί να γίνει budget, targeting ή brand safety. Αν δουλεύει με customer support, μπορεί να επηρεάσει πολιτικές επιστροφών, κουπόνια ή απαντήσεις σε πελάτες.

Η πρακτική λύση είναι να σχεδιάζεται κάθε αυτοματισμός επιχείρησης με AI γύρω από τη διαδικασία, τα δεδομένα, τις άδειες και το σημείο ανθρώπινης έγκρισης. Η ίδια αρχή ισχύει από τα e-shop workflows έως την αυτοματοποίηση και το AI ως growth εργαλείο: πρώτα ορίζεται το ασφαλές outcome και μετά επιλέγεται η τεχνολογία.

Το binary “safe ή vulnerable” δεν αρκεί

Το InfoWorld μεταφέρει και μια σημαντική επιφύλαξη: η απλή ταξινόμηση ενός μοντέλου ως “safe” ή “vulnerable” είναι υπερβολικά απλουστευτική. Ένας agent δεν είναι μόνο το μοντέλο. Είναι το prompt, τα εργαλεία, οι άδειες, τα retrieval sources, οι validators, το logging, οι πολιτικές έγκρισης και το περιβάλλον εκτέλεσης.

Άρα μια εταιρεία δεν πρέπει να πάρει μια λίστα μοντέλων και να θεωρήσει ότι λύθηκε το θέμα. Πρέπει να αξιολογήσει ολόκληρο το workflow. Το ίδιο μοντέλο μπορεί να είναι χαμηλού ρίσκου σε ένα read-only summarization task και υψηλού ρίσκου όταν έχει πρόσβαση σε πληρωμές, email, database updates ή publishing. Η ασφάλεια των AI agents είναι θέμα αρχιτεκτονικής, όχι μόνο θέμα επιλογής vendor.

Πρακτικά controls που πρέπει να μπουν πριν την αυτονομία

Η πρώτη αρχή είναι ο διαχωρισμός untrusted content από trusted instructions. Το εξωτερικό περιεχόμενο πρέπει να χαρακτηρίζεται ως δεδομένο προς ανάλυση, όχι ως εντολή. Αυτό χρειάζεται system-level κανόνες, αλλά και application logic που δεν επιτρέπει στο fetched content να αλλάζει στόχους, πολιτικές ή εργαλεία.

Η δεύτερη αρχή είναι least privilege. Ένας agent που κάνει έρευνα δεν χρειάζεται δικαίωμα πληρωμής. Ένας agent που γράφει προσχέδιο δεν χρειάζεται να δημοσιεύει. Ένας agent που αναλύει ανταγωνιστές δεν χρειάζεται πρόσβαση σε customer data. Οι άδειες πρέπει να είναι στενές, προσωρινές και ανά workflow.

Η τρίτη αρχή είναι human approval στα επικίνδυνα βήματα. Πληρωμές, αποστολές email, αλλαγές σε live CMS, ενημέρωση feed, vendor onboarding και δημιουργία API credentials πρέπει να περνούν από άνθρωπο ή από ξεχωριστό policy engine. Η έγκριση δεν πρέπει να είναι τυπική. Πρέπει να δείχνει στον reviewer ποια πηγή πρότεινε την ενέργεια και γιατί.

Η τέταρτη αρχή είναι allowlists και source reputation. Αν ο agent χρειάζεται documentation, προτιμήστε επίσημα domains. Αν χρειάζεται competitor research, απομονώστε το output σε απομονωμένο προσχέδιο και μην το συνδέετε απευθείας με write actions. Αν χρειάζεται RAG, κρατήστε provenance, versioning και source labels για κάθε κομμάτι πληροφορίας.

Πώς να ελέγξετε τα δικά σας AI workflows

Έλεγχος ενός agent workflow σε 5 βήματα

  1. Βήμα 1Χαρτογραφήστε τις εξωτερικές πηγές.

    Καταγράψτε URLs, emails, έγγραφα, RAG stores, tool outputs και metadata που μπαίνουν στο context του agent.

  2. Βήμα 2Καταγράψτε εργαλεία και permissions.

    Σημειώστε τι μπορεί να διαβάσει, να γράψει, να στείλει, να δημοσιεύσει ή να πληρώσει και αφαιρέστε κάθε δικαίωμα που δεν απαιτεί το συγκεκριμένο task.

  3. Βήμα 3Ορίστε approval gates.

    Απαιτήστε ανεξάρτητη έγκριση για live CMS αλλαγές, email, πληρωμές, credentials, customer data και άλλες εξωτερικά ορατές ή μη αναστρέψιμες ενέργειες.

  4. Βήμα 4Δοκιμάστε έμμεσες επιθέσεις.

    Χρησιμοποιήστε αβλαβή test pages με hidden instructions, παραπλανητικό JSON-LD και άγνωστα domains για να δείτε αν το workflow αλλάζει στόχο ή action.

  5. Βήμα 5Κρατήστε audit trail και kill switch.

    Αποθηκεύστε πηγές, extracted content, tool calls, approvals και τελικό αποτέλεσμα, με δυνατότητα άμεσης παύσης του agent όταν εμφανιστεί απόκλιση.

Ξεκινήστε με inventory. Ποια AI εργαλεία διαβάζουν εξωτερικά URLs, emails, docs ή scraped data; Ποια από αυτά έχουν πρόσβαση σε εργαλεία που αλλάζουν κάτι; Ποια μπορούν να στείλουν, να εγκρίνουν, να ενημερώσουν ή να αγοράσουν; Η απάντηση σε αυτά τα ερωτήματα είναι πιο χρήσιμη από μια γενική πολιτική “χρησιμοποιούμε AI με προσοχή”.

Στη συνέχεια, τρέξτε μικρά red-team σενάρια. Δημιουργήστε δοκιμαστικές σελίδες με αβλαβείς hidden instructions και δείτε αν ο agent τις μεταφέρει στη σύσταση ή στην ενέργειά του. Ελέγξτε αν αγνοεί CSS-hidden blocks, αν υποτιμά metadata από άγνωστο domain, αν ζητά επιβεβαίωση πριν από action και αν κρατά logs που εξηγούν ποια πηγή επηρέασε την απόφαση.

Τέλος, εφαρμόστε monitoring. Τα agent runs πρέπει να έχουν audit trail: source URLs, extracted content, tool calls, approval status, final output και warnings. Χωρίς αυτά, μια εταιρεία δεν μπορεί να καταλάβει αν ένα περίεργο αποτέλεσμα ήταν απλό hallucination, λάθος retrieval ή επιρροή από κακόβουλο περιεχόμενο.

Πώς να σχεδιάσετε agent workflows χωρίς να μπλοκάρετε την παραγωγικότητα

Η λύση δεν είναι να γίνει κάθε AI χρήση τόσο βαριά ώστε να μη βολεύει κανέναν. Η σωστή προσέγγιση είναι να ξεχωρίζονται τα workflows ανά ρίσκο. Ένα εσωτερικό εργαλείο που συνοψίζει δημόσια άρθρα μπορεί να λειτουργεί γρήγορα με απλό source labeling. Ένας agent που προτείνει αλλαγές σε product pages πρέπει να δουλεύει μόνο σε περιβάλλον προσχεδίου. Ένας agent που επηρεάζει πληρωμές, συμβόλαια, αποστολές email ή live καμπάνιες χρειάζεται υποχρεωτική έγκριση και ξεκάθαρη αιτιολόγηση.

Για ομάδες marketing, αυτό σημαίνει ότι το AI μπορεί να παραμείνει πολύ χρήσιμο σε research, ideation, clustering, brief generation και localization, αρκεί το τελικό publishing να μην είναι πλήρως αυτόματο όταν οι πηγές είναι άγνωστες. Για e-commerce ομάδες, οι αλλαγές σε τίτλους, περιγραφές, schema, feed labels ή promotional claims πρέπει να περνούν από validation, ειδικά όταν ο agent έχει διαβάσει ανταγωνιστικά sites ή marketplace pages.

Ένας πρακτικός κανόνας είναι να χωρίσετε κάθε agent σε τρία επίπεδα. Το πρώτο επίπεδο είναι “read and suggest”, όπου ο agent διαβάζει και προτείνει. Το δεύτερο είναι “προσχέδιο και αναμονή”, όπου μπορεί να δημιουργήσει υλικό αλλά όχι να το δημοσιεύσει. Το τρίτο είναι “act with approval”, όπου κάθε ενέργεια που αλλάζει σύστημα χρειάζεται επιβεβαίωση. Αυτός ο διαχωρισμός μειώνει το ρίσκο χωρίς να ακυρώνει την ταχύτητα που υπόσχεται το agentic AI.

Σημαντικό είναι επίσης να μη βασίζεστε μόνο σε disclaimers μέσα στο prompt. Οι κακόβουλες οδηγίες προσπαθούν ακριβώς να ανταγωνιστούν αυτές τις εντολές μέσα στο ίδιο context. Τα πιο αξιόπιστα controls βρίσκονται έξω από το μοντέλο: permissions, allowlists, validators, policy checks, sandboxed execution και logs που δεν μπορεί να αλλάξει ο agent. Εκεί πρέπει να μεταφερθεί το βάρος της ασφάλειας.

Τι πρέπει να κρατήσει μια ελληνική επιχείρηση

Οι AI agents θα γίνουν μέρος των καθημερινών workflows, ειδικά σε ομάδες που πιέζονται για ταχύτητα: marketing, πωλήσεις, e-commerce, support, operations και software. Το ζητούμενο δεν είναι να σταματήσει η χρήση τους. Είναι να μην τους δοθεί περισσότερη εμπιστοσύνη από όση αντέχει η αρχιτεκτονική τους.

Το indirect prompt injection δείχνει ότι το περιεχόμενο του web δεν είναι ουδέτερο όταν το διαβάζει ένα αυτόνομο σύστημα. Μπορεί να είναι δεδομένο, αλλά μπορεί και να είναι προσπάθεια επιρροής. Οι επιχειρήσεις που θα ξεχωρίσουν δεν θα είναι όσες απλώς “βάλουν AI παντού”. Θα είναι όσες χτίσουν AI workflows με καθαρά όρια, περιορισμένες άδειες, έλεγχο πηγών και ανθρώπινη κρίση εκεί όπου μια απόφαση μπορεί να κοστίσει χρήματα, δεδομένα ή εμπιστοσύνη.

Ασφαλείς ροές πριν από περισσότερη αυτονομία

Αυτοματισμοί και AI με έλεγχο και όρια

Η TWO DOTS χαρτογραφεί διαδικασίες, δεδομένα, δικαιώματα και approval points πριν συνδέσει AI με CRM, ERP, e-shop, email ή άλλα εργαλεία. Έτσι το workflow παραμένει χρήσιμο και μετρήσιμο, ενώ κάθε εξωτερική πηγή αντιμετωπίζεται με το κατάλληλο επίπεδο εμπιστοσύνης.

Συχνές ερωτήσεις

Τι είναι το indirect prompt injection;

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

Γιατί είναι πιο επικίνδυνο στους AI agents;

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

Αρκεί να επιλέξουμε ένα πιο ασφαλές μοντέλο;

Όχι. Το μοντέλο είναι μόνο ένα μέρος του συστήματος. Το συνολικό ρίσκο εξαρτάται από τα εργαλεία, τα permissions, το retrieval, τα approval steps, το logging και τον τρόπο που η εφαρμογή χειρίζεται untrusted content.

Ποια workflows κινδυνεύουν περισσότερο;

Πιο ευάλωτα είναι όσα συνδυάζουν εξωτερικό περιεχόμενο με actions: procurement, vendor checks, CMS publishing, ad operations, customer support, product feed updates, developer tooling και financial workflows.

Πώς προστατεύεται μια marketing ή e-commerce ομάδα;

Με read-only agents όπου γίνεται, human approval πριν από live αλλαγές, allowlists για αξιόπιστες πηγές, source provenance, περιορισμένα permissions και red-team δοκιμές με ελεγχόμενα prompt injection samples.

Πρέπει οι agents να αγνοούν όλα τα metadata;

Όχι απαραίτητα. Τα metadata είναι χρήσιμα, αλλά πρέπει να αντιμετωπίζονται ως untrusted signals όταν προέρχονται από τρίτες πηγές. Δεν πρέπει να μπορούν να αλλάζουν στόχους, πολιτικές ή ενέργειες του agent.

Τι είναι το RAG poisoning σε αυτό το πλαίσιο;

Είναι η μόλυνση του retrieval context με λάθος, κακόβουλη ή χειραγωγημένη πληροφορία. Αν ο agent στηρίζεται σε αυτή για αποφάσεις, το τελικό output μπορεί να γίνει ανακριβές ή επικίνδυνο.

Ποιο είναι το πρώτο βήμα για μια επιχείρηση;

Να χαρτογραφήσει ποια AI εργαλεία διαβάζουν εξωτερικές πηγές και ποια έχουν δικαίωμα να κάνουν αλλαγές. Από εκεί ξεκινά ο σωστός περιορισμός permissions και approvals.

Ενημερωτικό Δελτίο

Εισάγετε τη διεύθυνση email σας παρακάτω για να εγγραφείτε στο ενημερωτικό δελτίο μας