Guide d’intégration

Anomia se place entre n’importe quel client IA (Claude, ChatGPT, Mistral, agents personnalisés) et vos outils métier — chaque intégration arrive comme un upstream MCP brokeré (Notion, Slack, GitHub, HubSpot… ; Google Drive et Microsoft 365 reviendront post-lancement quand leurs serveurs MCP officiels seront publiés). C’est une infrastructure, pas un agent : elle ne raisonne pas, ne génère pas, ne décide pas — elle route, authentifie, autorise, classe, filtre, et audite.

Ce guide est la vue d’ensemble architecturale qu’un ingénieur sénior (ou un DSI / RSSI) doit avoir avant d’intégrer.

L’architecture en un paragraphe

Anomia est un broker : elle parle au serveur MCP de l’outil upstream et expose un point d’accès MCP unifié aux clients IA (Streamable HTTP à /v1/mcp). Elle ne réinvente pas les intégrations — elle met une couche de gouvernance devant le serveur de l’outil. Un seul point d’accès Anomia, n’importe quel nombre de serveurs MCP upstream brokés, trace d’audit complète. (ADR-017.)

Surfaces d’authentification

Il existe deux types d’appelant, gouvernés par le même modèle de permissions à six rôles.

Humains (console + API admin)

OAuth 2.0 + PKCE avec Google ou Microsoft Entra, ou
SSO d’entreprise via un SsoConnector par tenant (SAML 2.0 ou OIDC, routé par BoxyHQ Jackson auto-hébergé — aucun sous-traitant américain dans le chemin d’authentification).
MFA (TOTP, RFC 6238) est obligatoire pour owner et admin par défaut ; configurable par tenant. L’auto-désactivation est bloquée pour les rôles requis ; seul un reset par un owner peut effacer la MFA — ce qui révoque aussi les sessions de la cible.
Les sessions sont réelles : un claim session_id rattache le JWT d’accès (1 h) à une ligne serveur portant l’enveloppe d’expiration idle/absolute + le flag de révocation. Les refresh tokens tournent à chaque usage ; la réutilisation d’un token déjà tourné est traitée comme un vol et révoque toute la session. La déconnexion deny-liste le jti du JWT dans Redis (effet immédiat) et marque la session révoquée.

Clients IA (identités machine)

Clés API émises dans la console — ano_live_<256-bit-random>, stockées uniquement sous forme de hachage SHA-256.
Une clé est rattachée à un tenant et (optionnellement) à une identité d’agent (ADR-024). Un agent est un citoyen de premier rang aux côtés des humains : même audit, même RBAC, même plafond de classification — le max_data_class par agent borne les outils que l’agent peut appeler indépendamment du tag de l’outil.

Rôles : owner, admin, compliance_officer, team_lead, member, auditor (ADR-025). L’autorité d’un team-lead est bornée par son team_id.

Le point d’accès MCP

Anomia expose un serveur MCP conforme à la spec à /v1/mcp (transport Streamable HTTP). Après authentification avec une clé API en Bearer, un client IA peut :

tools/list → retourne tous les outils brokés que l’identité appelante est autorisée à voir (filtré par tool-gating par agent + plafond de classe de données).
tools/call → relayé vers le bon serveur MCP upstream, avec les identifiants de l’identité appelante.

Chaque appel relayé passe par le modèle de sécurité IA à cinq couches avant d’atteindre l’upstream :

Couche	Action
1	DLP en sortie + scan d’injection sur les arguments d’outil (ADR-022).
2	Autorisation (RBAC + tool-gating par agent + plafond de classe).
3	(volontairement légère — filtrage des contenus retournés, pas des arguments).
4	Confirmation des actions sensibles — les opérations destructives re-demandent une confirmation via un token HMAC (ADR-031).
5	Limites de débit comportementales par identité (par minute, par heure, destructive — ADR-032).

Les barrières qualitatives (1, 2, 4) échouent fermées. Les limites de débit (5) échouent ouvertes avec audit — l’abuse-mitigation est quantitative, pas une barrière de sécurité ; une panne Redis ne doit pas se transformer en DoS auto-infligé.

Classification des données

Chaque outil et chaque upstream peut porter une classe de données (ex. public < internal < confidential < secret_pro). Les agents portent un plafond max_data_class ; un appel à un outil dont la classe effective dépasse le plafond de l’agent est refusé + audité. L’échelle est par tenant et éditable dans la console (ADR-026).

Journal d’audit

Chaque changement d’état et chaque appel broké inscrit une ligne dans un journal d’audit immuable, en chaîne de hachage (chaîne SHA-256 par tenant). La chaîne est vérifiable côté client : exportez en CSV et re-marchez la chaîne vous-même. La rétention dépend du plan (90 jours → 3 ans ; configurable sur Enterprise/Sovereign).

Les événements de refus — permission denied, rate-limited, échec MFA, vol de refresh-token, mismatch du domaine e-mail SSO — sont écrits sur une session committing pour survivre à un rollback de requête (ADR-030). La trace forensique est la trace d’audit production-grade.

Souveraineté européenne

Par conception : Hetzner Falkenstein (Allemagne) pour le compute, Postgres + Redis sur le même VPC, BoxyHQ Jackson auto-hébergé pour le SSO, TOTP local (aucun fournisseur SMS/push), et aucun sous-traitant américain dans le chemin d’authentification. Le Centre de confiance (/trust) liste explicitement chaque sous-traitant et la posture de résidence.

Volontairement hors-scope aujourd’hui

Webhooks sortants — post-lancement.
Mapping automatique groupe IdP → rôle — post-V1 ; le JIT pose les utilisateurs au default_new_user_role du connecteur, l’admin élève explicitement.
WebAuthn / passkeys — post-V1.
SCIM — post-V1.
Déploiement multi-région — la cible de lancement est mono-région (DE).

Si vous avez besoin d’une image architecturale plus précise pour un cas particulier, répondez à votre e-mail d’accès — on en discute volontiers.