Poser des questions sur votre infra depuis un chat Claude. Comment fonctionne le serveur MCP, quels 12 outils sont disponibles, et pourquoi nous n'autorisons délibérément aucune Emergency Action autonome.

Quand vous configurez le Claude Connector monsys, vous pouvez poser depuis un chat Claude des questions comme « quels serveurs ont une CVE critique ouverte ? » ou « quel est le Trust Score de mon tenant ? ». Claude appelle alors des outils MCP sur le hub monsys et vous donne un résumé.

Cet article décrit comment ce connector fonctionne techniquement, quel flow OAuth est utilisé, quels outils sont disponibles, et — peut-être plus important — ce que le connector ne fait pas, délibérément.

MCP : Model Context Protocol en un paragraphe

MCP est un protocole ouvert (Anthropic, fin 2024) qui définit comment un modèle IA peut appeler des outils sur des serveurs externes. Un serveur MCP publie une liste d'outils disponibles via une interface JSON-RPC. Le client (Claude) appelle des outils en envoyant une requête tools/call avec le nom de l'outil et ses arguments.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "monsys_list_alerts",
    "arguments": {
      "severity": "critical",
      "limit": 10
    }
  }
}

Le serveur MCP (le hub monsys sur api.monsys.ai) traite l'appel, récupère les données depuis la base, et retourne une réponse structurée. Claude interprète cette réponse et formule une réponse.

OAuth 2.1 avec PKCE : le flow d'auth

Le connector utilise OAuth 2.1 avec PKCE (Proof Key for Code Exchange). C'est la best-practice actuelle pour les clients publics (comme les apps basées navigateur) qui ne peuvent pas stocker un client secret de manière sécurisée.

Discovery

Claude détecte la configuration OAuth via :

GET https://api.monsys.ai/.well-known/oauth-authorization-server

Response:
{
  "issuer": "https://api.monsys.ai",
  "authorization_endpoint": "https://app.monsys.ai/mcp/oauth/authorize",
  "token_endpoint": "https://api.monsys.ai/mcp/oauth/token",
  "registration_endpoint": "https://api.monsys.ai/mcp/oauth/register",
  "scopes_supported": ["mcp.read", "mcp.acknowledge"],
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"]
}

Enregistrement

Un client (votre propre script, ou Claude) s'enregistre :

curl -X POST https://api.monsys.ai/mcp/oauth/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "claude-desktop",
    "redirect_uris": ["https://claude.ai/oauth/callback"]
  }'

# Response:
# { "client_id": "mcp_a1b2c3...", "client_secret": null }

Pas de client_secret — c'est un client public.

Flow d'autorisation

1. Client génère PKCE :
   verifier  = random_bytes(32).hex()
   challenge = base64url(sha256(verifier))

2. Redirect vers l'endpoint d'autorisation :
   https://app.monsys.ai/mcp/oauth/authorize
     ?client_id=mcp_a1b2c3
     &redirect_uri=https://claude.ai/oauth/callback
     &response_type=code
     &scope=mcp.read
     &code_challenge=<challenge>
     &code_challenge_method=S256

3. L'utilisateur se connecte à monsys et approuve les scopes

4. Redirect avec authorization code :
   https://claude.ai/oauth/callback?code=<code>

5. Token exchange :
   POST /mcp/oauth/token
     grant_type=authorization_code
     &code=<code>
     &redirect_uri=...
     &client_id=mcp_a1b2c3
     &code_verifier=<verifier>

6. Response :
   {
     "access_token": "mat_...",
     "token_type": "Bearer",
     "expires_in": 3600,
     "scope": "mcp.read"
   }

TTL du token : 1 heure. Après cela, ré-authentification requise.

Les 12 outils disponibles

Tous les outils sauf un sont read-only. Le scope mcp.read donne accès aux outils en lecture ; mcp.acknowledge est nécessaire pour l'unique outil en écriture.

Outil	Quoi	Question Claude typique
`monsys_kpi_summary`	Snapshot fleet : Trust Score, alertes ouvertes, détections ouvertes, statut SLA	« Donne-moi un morning briefing de mon infra »
`monsys_list_agents`	Hôtes actifs avec filtre par tag	« Quels serveurs de production sont en ligne ? »
`monsys_get_agent`	Détail par hôte : CPU/mem/disk + alertes ouvertes	« Comment va web-edge-01 ? »
`monsys_trust_score`	Trust Score + 8 composantes + delta 7j	« Mon Trust Score s'est-il amélioré cette semaine ? »
`monsys_list_alerts`	Alertes ouvertes filtrées par severity/category/agent	« Quelles alertes critical sont ouvertes ? »
`monsys_list_detections`	Événements de détection (24h/7j/30j)	« Y a-t-il eu des événements de sécurité hier ? »
`monsys_get_detection`	Drill-down : contexte complet + événements liés + suggestions	« Explique-moi cet événement de détection »
`monsys_acknowledge_detection`	Ferme une détection après investigation	« Acquitte l'événement DEV-2026-0441 »
`monsys_list_kernel_cves`	CVE noyau ouvertes avec compte d'hôtes affectés	« Quelles CVE noyau restent ouvertes ? »
`monsys_list_os_cves`	CVE de packages OS depuis OSV.dev	« Quelles CVE npm a mon fleet ? »
`monsys_list_sla_overview`	Cibles SLA avec % observé et error budget	« À quelle distance suis-je de mon seuil SLA ? »
`monsys_audit_log_search`	Grep audit_log par event_type/actor/time	« Qui a exécuté des Emergency Actions la semaine passée ? »

Chaque appel d'outil est journalisé

Ce n'est pas un détail — c'est une garantie architecturale. Chaque invocation d'outil via le Claude Connector est stockée dans mcp_call_log :

CREATE TABLE mcp_call_log (
    id          UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    tenant_id   UUID NOT NULL,
    user_id     UUID NOT NULL,
    tool_name   TEXT NOT NULL,
    args_hash   TEXT NOT NULL,
    result_status TEXT NOT NULL,
    duration_ms INT NOT NULL,
    called_at   TIMESTAMPTZ DEFAULT NOW()
);

Les arguments bruts ne sont pas stockés (risque PII), uniquement le hash SHA256. Le log est interrogeable via l'outil d'audit lui-même :

monsys_audit_log_search(event_type='mcp_tool_invoked', since='7d')

Pour les contextes de conformité c'est important : si Claude a récupéré des données pour le compte d'un opérateur, c'est dans l'audit trail.

Pourquoi le connector est read-mostly

La question la plus posée par les équipes sécurité : « Claude peut-il exécuter des Emergency Actions automatiquement ? »

Non. Délibérément.

Les actions destructrices — IsolateNetwork, KillProcess, mises à jour noyau, lockout utilisateur — exigent :

Vérification TOTP de l'opérateur
Une raison d'au moins 20 caractères
Un Emergency Action Token (EAT) signé par le hub avec Ed25519

Ce processus ne peut pas être automatisé via le Claude Connector. Le seul outil en écriture est monsys_acknowledge_detection — fermer un événement de détection après investigation, ce qui est entièrement réversible et journalisé.

La raison est principielle, pas technique : un agent IA qui peut isoler de manière autonome des serveurs de production du réseau est un modèle de risque différent d'un agent IA qui vous aide à rassembler de l'information et à préparer des décisions. Nous choisissons le second.

Cela rejoint le principe human-in-the-loop qu'utilise aussi le système CLUE d'Anthropic : Claude suggère, l'opérateur décide.

Souveraineté : qu'est-ce qui passe par l'API de Claude ?

Cela mérite une section explicite. Quand vous utilisez le connector, les réponses des outils passent par l'API d'Anthropic pour être traitées par le modèle. Cela signifie :

Ce qui PASSE par l'API de Claude :

Hostnames et adresses IP
Titres et descriptions d'alertes
Métadonnées d'événements de détection (src_ip, target_user)
Chiffres Trust Score
Identifiants CVE

Ce qui NE PASSE PAS par l'API de Claude :

Pas de données brutes côté agent (le connector lit la DB du hub, pas les ressources de l'hôte)
Pas de secrets ou credentials
Pas de bodies bruts d'audit-log (uniquement event_type + métadonnées)
Pas de contenu de traces AI observability (prompts/completions)

Pour la plupart des contextes NIS2, c'est acceptable. Pour les administrations ou secteurs avec exigences strictes de data-residency (défense, certaines parties de la santé) le connector est opt-in par tenant et peut rester désactivé.

Le connector est un outil pour les opérateurs qui veulent interroger leur infra en langage naturel. Il n'est pas conçu comme un agent de sécurité autonome.

Un exemple pratique : morning briefing comme routine Claude

Sauvegardez ceci comme routine Claude (quotidien 08:00) :

Ouvre le connector monsys. Appelle monsys_kpi_summary.
Donne un update style Slack :
- Trust Score : X/100 (delta vs hier : +/-)
- Alertes critical ouvertes : N
- Détections ouvertes (24h) : N
S'il y a des détections critical, appelle aussi monsys_list_detections(since=24h, ack=open)
et donne une ligne par événement : [agent] [rule_kind] [premier vu]

Claude assemble les données via deux appels d'outils, corrèle là où nécessaire, et vous donne un résumé lisible — sans que vous ayez à ouvrir le dashboard.

Le Claude Connector est documenté dans docs.monsys.ai/fr/hub/claude-connector. Les cinq premiers serveurs gratuits, flow OAuth fonctionnel directement après inscription : monsys.ai/fr/signup.

Le Claude Connector monsys : MCP, OAuth 2.1 et pourquoi l'agent n'agit jamais de manière autonome