Modèle de sécurité

Orienté agents ne signifie pas incontrôlé. Un système MCP-first décrit chaque capacité de manière lisible par les machines, et détermine simultanément qui peut l’appeler, sous quelles conditions, et quelles traces sont laissées. La sécurité n’est pas un ajout postérieur, mais fait partie de la conception des capacités.

Six niveaux d’autorisation

L’authentification répond à : Qui es-tu ? L’autorisation répond à : Que peux-tu faire ? Un système MCP-first a besoin des deux questions, et y répond sur six niveaux indépendants qui déterminent ensemble l’accès effectif.

Niveau 1 : Rôle utilisateur

Le rôle de l’utilisateur connecté forme le niveau le plus large. Il détermine les classes d’accès fondamentales, pas les outils individuels.

admin
manager
employee
viewer
external_client

Niveau 2 : Portée du tenant

Dans les systèmes multi-tenant, chaque accès doit être lié au tenant. Aucun agent ne peut lire ou écrire entre tenants, même si son rôle utilisateur le permettrait techniquement.

tenant:abc
project:123
contact:456

Niveau 3 : Portée de l’outil

Chaque outil est sécurisé avec ses propres scopes. Un agent reçoit exclusivement les scopes nécessaires à sa tâche définie.

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

Niveau 4 : Portée de ressource

Au-delà des scopes d’outils, l’accès peut être restreint à des types de ressources individuels. Cela garantit qu’un agent avec contacts:read ne peut toujours pas consulter chaque ressource de contact.

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

Niveau 5 : Niveau de risque

Chaque outil porte un niveau de risque déclaré. Ce niveau est pris en compte dans la politique de confirmation et la configuration d’audit.

Niveau 6 : Politique de confirmation

La politique de confirmation détermine quelle étape supplémentaire doit être franchie avant l’exécution. Elle est configurée par outil et imposée par la couche de politique, pas par l’agent lui-même.

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

Visibilité des outils

Si un outil existe est déjà une information liée à la sécurité. Un agent qui connaît un outil interdit peut l’utiliser comme surface d’attaque, même si l’appel ultérieur serait bloqué.

Un assistant commercial reçoit par exemple la liste d’outils filtrée suivante :

Human-in-the-loop

MCP-first ne signifie pas entièrement automatique. Cela signifie entièrement contrôlable, mais de manière contrôlée. Pour les actions sensibles ou risquées, le système interrompt l’agent et sollicite activement le consentement de l’utilisateur.

L’agent reconnaît à partir des métadonnées de risque déclarées qu’une action nécessite une approbation humaine, et transfère le contrôle. Ce n’est qu’après une confirmation explicite que l’outil est exécuté.

L’exemple suivant montre un dialogue d’approbation typique pour l’envoi en masse d’e-mails externes, l’une des actions d’agent critiques les plus courantes :

Authentification renforcée

Pour les actions particulièrement sensibles, une session active ne suffit pas. Même un administrateur connecté doit reconfirmer son identité avant que des opérations critiques soient exécutées.

Déclencheurs typiques pour l’authentification renforcée :

• Modifier ou attribuer des droits d’administrateur
• Modifier des données de paiement ou d’abonnement
• Données salariales ou exports de paie
• Créer ou faire tourner des clés API
• Exports complets de données
• Supprimer des utilisateurs ou des tenants

Méthodes d’authentification renforcée acceptées (selon la politique système) :

Nouvelle saisie du mot de passe
TOTP / Application d'authentification
Passkey
Approbation d'administrateur par une seconde personne
Principe des quatre yeux

Registre de consentement

Chaque consentement à une action d’agent est un événement qui devrait être stocké de manière permanente. Le registre de consentement permet de retracer rétrospectivement quelle action a été approuvée par qui, pour quel périmètre et avec quelle méthode de sécurité.

Champs stockés d’une entrée de consentement :

consentId, identifiant unique du consentement
userId, utilisateur approbateur
agentId, agent agissant
clientId, client MCP connecté
toolName, outil appelé
inputSummary, résumé structuré des entrées (pas en clair)
riskLevel, niveau de risque déclaré de l'outil
approvedAt, horodatage de l'approbation
expiresAt, validité de l'approbation (si limitée dans le temps)
approvalMethod, méthode d'approbation utilisée (ex. : "totp", "passkey", "manual")

Certaines approbations peuvent être valides pour une durée limitée, par exemple une approbation unique pour un envoi concret. D’autres sont valides pour une session ou une période configurée. La politique détermine la granularité.

Piste d’audit

Chaque action MCP génère une entrée d’audit. Cette entrée est immuable, liée au tenant et exploitable par les machines. Elle constitue la base des preuves de conformité, de la détection d’anomalies et des revues internes.

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

Le journal d’audit peut être surveillé automatiquement pour détecter des anomalies : fréquences d’exécution inhabituelles, actions en dehors des heures de travail habituelles ou accès à des scopes qu’un agent n’utilise normalement pas, tout cela est détectable parce que chaque action est proprement typée et auditée.