Connector Claude (MCP)

monsys.ai publie un serveur Model Context Protocol (MCP) que vous pouvez ajouter comme Custom Connector dans Claude. Depuis un chat ou une routine Claude peut appeler des tools comme “lister alertes ouvertes”, “donner Trust Score”, “drill into cette détection”.

Selon feedback_human_in_the_loop les tools sont en lecture-mostly. Claude peut voir + résumer + suggérer, jamais exécuter. Les actions destructives (IsolateNetwork, kernel update, user lock) restent TOTP-gated dans le tableau de bord. Seul tool en écriture : monsys_acknowledge_detection — ferme un detection event après investigation (entièrement réversible, audit-logged).

Dans le tableau de bord (côté Claude)

Ouvrez Claude desktop ou claude.ai
Settings → Connectors → Add custom connector
URL : https://api.monsys.ai
Claude découvre OAuth via /.well-known/oauth-authorization-server
Cliquez Connect → vous êtes envoyé vers app.monsys.ai/login
Connectez-vous avec votre compte monsys → approuvez scope mcp.read mcp.acknowledge
Retour dans Claude : statut connector “Connected”

TTL token : 1 heure. Ensuite Claude affiche un bouton re-auth. Refresh tokens en v2.

Tools disponibles

Tool	Quoi	Scope
`monsys_list_agents`	hôtes actifs avec filtre tag	read
`monsys_get_agent`	détail par hôte (CPU/mem/disk + alertes ouvertes)	read
`monsys_trust_score`	score tenant actuel + 6 composants + delta 7j	read
`monsys_list_alerts`	alertes ouvertes filtrées par sévérité/catégorie/agent	read
`monsys_list_detections`	detected_events dernières 24h/7j/30j avec filtre	read
`monsys_get_detection`	drill-down : contexte complet + auth-events liés + findings similaires + suggested next steps	read
`monsys_acknowledge_detection`	ferme une détection après investigation (réversible)	acknowledge
`monsys_list_kernel_cves`	CVEs noyau ouvertes avec count hosts affectés	read
`monsys_list_os_cves`	CVEs paquets OS ouvertes via OSV.dev (apt/dnf/apk/zypper)	read
`monsys_list_sla_overview`	tous les targets SLA avec observed%/error budget	read
`monsys_audit_log_search`	grep audit_log par event_type/actor/time	read
`monsys_kpi_summary`	snapshot flotte one-shot pour briefings du matin	read

Chaque tool call est loggé dans mcp_call_log avec tool_name + tenant + user + duration + result_status. Visible dans l’audit log du dashboard via monsys_audit_log_search(event_type='mcp_tool_invoked').

Exemples — routines Claude

Daily morning briefing (08:00 lun-ven)

Sauvegardez comme routine Claude :

“Ouvre le connector monsys. Appelle monsys_kpi_summary. Formate en update style Slack court : Trust Score X/100, Y alertes critiques ouvertes, Z détections ouvertes 24h. S’il y a des détections, appelle aussi monsys_list_detections(since=24h, ack=open) et donne un résumé 1-ligne par event.”

Investigation IP source inconnue

“Dans monsys je vois une alerte depuis IP 185.220.101.42. Appelle monsys_audit_log_search(actor_email_contains='@yourMSP.com') pour les 24h dernières ET monsys_list_detections(since=7d) filtré sur cet IP. Résume ce que cet IP a tenté et suggère si c’est suspect.”

Check cross-tenant MSP

Un connector par tenant. Dans votre workspace MSP utilisez une conversation Claude séparée par client avec le bon connector activé :

“Dans monsys-acme : monsys_kpi_summary. Dans monsys-eu-bank : monsys_kpi_summary. Compare les deux et flag le tenant avec le plus grand delta depuis hier.”

Sovereignty + confidentialité

Important à dire explicitement aux prospects : Claude est Anthropic (société US). Quand vous appelez un tool les données passent par l’API de Claude pour être envoyées au modèle. Pour certains tenants (gouvernement, certains secteurs NIS2) c’est un dealbreaker. Le connector est donc opt-in par tenant.

Ce qui ne passe PAS par Claude :

Pas de données côté agent (le connector lit la DB hub, pas les ressources host)
Pas de secrets, pas de credentials (les tools retournent données tenant scopées au RBAC user)
Pas de bodies raw audit-log (uniquement event_type + métadonnées)

Ce qui passe par Claude :

Hostnames, adresses IP, country codes
Titres + descriptions d’alertes
Detection event src_ip + target_user
Trust Score numbers

Pour l’acheteur audit NIS2 c’est acceptable ; pour un architecte d’agence de renseignement non. Faites le choix explicite par client.

Gestion de session

Révoquer tokens : dashboard → /settings/mcp-tokens (v2 ; pour l’instant via SQL : UPDATE mcp_access_tokens SET revoked_at=NOW() WHERE user_id='<uuid>')
Audit par connector : monsys_audit_log_search(event_type='mcp_authorization_granted')
Audit par call : table mcp_call_log montre chaque tool call avec hash arguments (raw args non stockés pour des raisons PII)

Ou via API (avancé — pour automatisation)

Roundtrip MCP direct avec votre propre client (sans UI Claude) :

# 1. Enregistrer un client
curl -X POST https://api.monsys.ai/mcp/oauth/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"my-script","redirect_uris":["http://localhost:8080/cb"]}'

# 2. Flow browser : ouvrez
# https://api.monsys.ai/mcp/oauth/authorize?client_id=mcp_xxx&redirect_uri=http://localhost:8080/cb&response_type=code&code_challenge=<sha256-of-verifier>&code_challenge_method=S256&scope=mcp.read
# loggez-vous si besoin → redirect avec ?code=xxx

# 3. Échanger code contre token
curl -X POST https://api.monsys.ai/mcp/oauth/token \
  -d "grant_type=authorization_code&code=xxx&redirect_uri=http://localhost:8080/cb&client_id=mcp_xxx&code_verifier=<original>"

# 4. Appeler un tool
curl -X POST https://api.monsys.ai/mcp \
  -H "Authorization: Bearer mat_xxx" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"monsys_kpi_summary","arguments":{}}}'

Ce qui n’appartient PAS à cette page

Emergency Actions manuelles (IsolateNetwork etc.) → voir Emergency console
Module OpenAI Admin Audit (autre direction : monsys lit OpenAI/Copilot) → voir OpenAI Audit
Étude de cas Anthropic → voir blog