Bonnes pratiques

Bonnes pratiques pour le serveur MCP géré par Okta.

Version en accès anticipé

Modèle d'hébergement

Ne pas connecter le serveur MCP Okta Open Source et le serveur MCP géré par Okta au même client LLM en même temps. Des outils redondants entre les deux serveurs peuvent entrer en conflit et empêcher le LLM de déterminer quel outil utiliser.

Appliquer le principe du moindre privilège. Accordez uniquement les permissions OAuth spécifiques dont votre équipe a besoin pour ses tâches opérationnelles.
Révisions de validation régulières. Vérifier régulièrement les permissions d'intégration de votre app dans la console des administrateurs Okta afin de supprimer les autorisations inutiles.
Séparer les apps par rôle. Créer des apps OIDC distinctes pour les différents types d'utilisateurs afin de maintenir des pistes d'audit claires et d'appliquer les niveaux d'accès appropriés.

Examiner attentivement les résultats de l'opération de lecture. Bien que les hallucinations dans les résultats de lecture seule soient moins probables lorsque les requêtes restent dans les limites de la fenêtre contextuelle, toujours vérifier les données renvoyées avant d'agir.
Utiliser les opérations d'écriture avec prudence. La plupart des cas d'utilisation impliquent des opérations de lecture. Si votre org exige des opérations d'écriture, s'assurer d'avoir examiné attentivement les résultats avant de poursuivre, car certaines actions peuvent être irréversibles.
Comprendre la nature non déterministe de l'IA. Les résultats peuvent différer d'une session à l'autre. Il s'agit d'un comportement attendu.
Vérifier les résultats à fort enjeu. Pour les tâches sensibles (vérification de départ et audits de sécurité), contrôler manuellement un échantillon avant de se fier au résultat à grande échelle.

Suivre les bonnes pratiques relatives aux invites. Utiliser des invites claires, spécifiques et concises afin de réduire l'ambiguïté et d'améliorer l'exactitude des résultats.
Délimiter précisément le périmètre des invites. Cibler un groupe, une app, une plage de dates ou un segment d'utilisateurs spécifique plutôt que de demander « tout » d'un coup. Des invites trop larges forcent le modèle à extraire de grands ensembles de données à travers de nombreux outils, augmentant l'utilisation des jetons et ralentissant les réponses.
Indiquer les seuils et les critères exacts dans votre invite. Inclure des règles concrètes (par exemple, « Plus de 90 jours d'inactivité », « centre de coûts 1001-1050 », « SLA de 3 jours ») afin que l'agent évalue selon votre standard plutôt que de faire des suppositions.
Regrouper les questions similaires. Combinez tout ce que vous souhaitez savoir sur une entité (par exemple, les groupes d'un utilisateur, les attributions d'app et l'historique de connexion) en une seule invite bien structurée au lieu d'envoyer plusieurs petits suivis.

Traiter les actions d'écriture comme des brouillons à réviser. Les invites de lecture seule ou d'audit (rechercher, signaler, lister) présentent un risque faible ; les actions qui modifient l'état (désactiver, révoquer, supprimer) doivent être examinées avant leur exécution, en particulier au début, le temps que la confiance dans l'outil s'installe.
Commencer par des invites en lecture seule avant d'autoriser les modifications en bloc. Valider la précision de l'agent sur les tâches d'audit avant de lui permettre d'exécuter des actions d'écriture en masse (par exemple, désactivation en masse, modifications de groupe en masse, suppression de politique).
Confirmer les actions irréversibles avant de continuer. Certaines opérations d'écriture sont irréversibles (suppressions et annulation de l'approvisionnement, par exemple).

Tenir compte des seuils de protection des API. Les dépasser entraîne des réponses HTTP 429 et peut avoir un impact sur les performances.
Surveiller les limites de la fenêtre contextuelle pour les requêtes volumineuses. Les jeux de données très volumineux extraits en une seule requête augmentent le risque de résultats incomplets ou dégradés.