Πως να προστατέψετε τους agents & το περιβάλλον σας.

Σε αυτό το άρθρο θα δούμε τους πιο γρήγορους τρόπους για να διασφαλίσουμε στο έπακρο την χρήση των Ai tools στο 365.

Soft hardening

Από το admin 365 πάνελ σας:

Ένα από τα νέα features στο οικοσύστημα του Microsoft 365 είναι η σελίδα Agent settings στο Microsoft 365 admin center. Τι διαχειρίζεσαι εδώ; Τους AI agents που βοηθάνε στη δουλειά, αλλά που… χωρίς καθοδήγηση, μπορεί να γίνουν επικύνδυνο παιχνίδι!

Η σελίδα Agent settings είναι το κεντρικό σημείο ελέγχου για να καθορίσεις ποιοι πράκτορες AI μπορούν να υπάρχουν, ποιος τους μοιράζεται, ποιος τους χρησιμοποιεί και με ποιους κανόνες δουλεύουν.

Allowed agent types — Ποιοι agents έχουν κάρτα εισόδου;

Εδώ αποφασίζεις τι είδους πράκτορες “τρέχουν” μέσα στην εταιρεία. Οι επιλογές είναι:

Agents από την ίδια τη Microsoft
Agents που έχει φτιάξει η δική σου εταιρεία
Agents από external publishers (δηλαδή τρίτους)

Best practices:

 Microsoft agents & Organizational agents

Γιατί;
Γιατί δεν θέλεις agent από τρίτο publisher που “βοηθάει” αλλά τραβάει δεδομένα σε άγνωστο tenant.

Sharing — Ποιος μοιράζεται τι;

Είναι ιδιαίτερα χρήσιμο όταν θέλεις να αποφύγεις το χαμό του «έστειλα αυτό το bot σε όλο τον οργανισμό»

Best practise:

❌ Disabled για όλους

✅ Enabled μόνο για ομάδα “AI Users”

Γιατί;
Για να μη γίνει viral agent τύπου: “Έφτιαξα ένα bot που διαβάζει όλα τα Excel, δείτε το!”

User access — Ποιος παίζει με τους agents;

Εδώ ορίζεις ποιοι χρήστες ή ομάδες έχουν δικαίωμα να χρησιμοποιούν agents:

Best Practise:

Allowed μόνο σε συγκεκριμένες ομάδες (πχ IT, BI, Ops)

👉 AI adoption σταδιακά

All agents

Microsoft 365 Admin Center → Copilot → Agents → All agents

Ένα ακόμα ενδιαφέρον στοιχείο προς παραμετροποίηση είναι η επιλογή All agents. Εδώ βλέπεις όλους τους AI agents που κυκλοφορούν στο tenant σου – και αποφασίζεις ποιοι είναι ok και ποιοι… κόβονται.

Η λίστα που βλέπεις (Researcher, Excel Frontier, Word Frontier κ.λπ.) είναι το agent registry του οργανισμού:

  • Ποιος agent υπάρχει
  • Ποιος τον έφτιαξε (Microsoft ή οργανισμός)
  • Πού είναι διαθέσιμος
  • Σε ποιο channel (Copilot, Teams, Office apps)

τι μπορείς να του κάνεις ως admin

Block agent – το κουμπί που σώζει ζωές (και audits)

Το Block ΔΕΝ είναι uninstall.
Είναι άμεσο kill switch.

Τι σημαίνει Block:

  • ❌ Ο agent σταματά να είναι διαθέσιμος
  • ❌ Οι χρήστες δεν μπορούν να τον καλέσουν
  • ❌ Δεν τραβά δεδομένα
  • ❌ Δεν εκτελεί prompts

👉 Ιδανικό για:

  • agent που δεν έχει εγκριθεί
  • agent με λάθος scope
  • agent που “κάνει πολλά”

Remove – πιο δραστικό, πιο μόνιμο

Το Remove:

  • αφαιρεί τον agent από το registry

Real-life use case (από την πραγματικότητα)

HardCore Settings

Θα το βρεις στο admin.powerplatform.microsoft.com

Η ρύθμιση που καίει credits χωρίς να το καταλάβεις 

Αν χρησιμοποιείς Power Apps, Power Automate ή Copilot Studio, τότε χρησιμοποιείς (άμεσα ή έμμεσα) AI Builder.
Και ο AI Builder… δεν δουλεύει με αγάπη, δουλεύει με credits.

Το πρόβλημα;
Υπάρχει μια ρύθμιση που, αν είναι ανοιχτή, επιτρέπει στους χρήστες να καταναλώνουν tenant-wide credits χωρίς να το ξέρουν.

Τι σημαίνει αυτή η ρύθμιση στην πράξη

✅ Όταν είναι ENABLED

  • Environments χωρίς assigned AI Builder credits
  • μπορούν να χρησιμοποιούν tenant-level unassigned credits
  • οποιοσδήποτε χρήστης με δικαιώματα μπορεί:
    • να τρέξει AI Builder actions
    • να καταναλώσει credits
    • χωρίς visibility, χωρίς έλεγχο

Γιατί είναι επικίνδυνο

  • Δεν ξέρεις:
    • ποιο app καίει credits
    • ποιο flow τα τρώει
    • ποιος χρήστης τα ξεκίνησε
  • Ένα κακογραμμένο flow:

Best Practise:

Assign credits μόνο σε συγκεκριμένα environments

📍 Environments → [Environment] → Capacity

✔ Prod ή Specific Dev / AI Lab
❌ Όχι σε όλα !

Tenant Isolation

Τι κάνει το Tenant isolation

Με απλά λόγια:

Ελέγχει αν Power Platform apps & flows μπορούν να μιλάνε με άλλα tenants.

  • το Power Platform επιτρέπει by default
  • ειδικά σε:
    • custom connectors
    • HTTP actions
    • Copilot Studio integrations

IP address-based cookie binding


Και αν σου κλέψουν session cookie… δεν χρειάζονται καν credentials

attack scenario 

Cookie bind attack (απλά λόγια)

  1. Ο χρήστης κάνει login
  2. Δημιουργείται session cookie
  3. Κάποιος (malware, browser exploit, shared PC)αντιγράφει το cookie
  4. Ο attacker το χρησιμοποιεί σε άλλον υπολογιστή
  5. αποκτά πρόσβαση χωρίς login

Τι κάνει το IP-based cookie binding

Όταν είναι enabled:

  • Το Dataverse: dένει το session cookie με την IP address του υπολογιστή
  • Σε κάθε request: συγκρίνει IP cookie origin ↔ IP client

❌ Αν δεν ταιριάζουν → BLOCK
✔ Αν ταιριάζουν → συνεχίζει κανονικά

Προσοχή ! sε περιβάλλοντα με:

  • NAT
  • proxies
  • dynamic IPs

 Κάνε testing πριν full rollout (όχι disable by default).