odock.ai
Requête d'outil gouvernée
MCP Gateway

Gouvernez chaque appel d'outil de vos agents

Les agents ont besoin de plus qu'un simple proxy. Odock place un MCP gateway gouverné entre vos agents et chaque serveur en amont — en appliquant l'authentification, les politiques d'accès, les limites de dépenses et les enregistrements d'audit avant l'exécution de tout outil.

Réserver une démoLire le guide de gouvernance MCP

Une seule voie gouvernée pour chaque appel d'outil.

mcp-gateway.request
MCP Gateway
>POST /v1/mcp/tools/callruntime agent
01Accès agentvalidé
02Droits outil...
03Scan politique...
04Budget réservé...
05Route amont...
06Usage journalisé...
Transports
SSE, HTTP, STDIO
Contrôles
Politique, budget, audit
Qu'est-ce qu'une gateway MCP ?

Une couche de politique d'accés entre les agents IA et chaque outil qu'ils peuvent toucher

Une gateway MCP est un plan de contrôle placé entre les agents IA et les serveurs MCP qui exposent des outils comme GitHub, Slack et les bases de données. Plutôt que de laisser chaque agent détenir des credentials en amont et joindre chaque serveur directement, tout le trafic outils passe par un seul endpoint gouverné qui authentifie l'appelant, vérifie les permissions au niveau des outils, applique les budgets et enregistre chaque appel. Odock l'intègre à un unique plan de gouvernance IA : les mêmes keys, budgets et enregistrements d'audit gouvernent aussi bien votre trafic outils MCP que votre trafic LLM.

Où les équipes l'utilisent

Contrôle d'accès aux outils des agents

N'exposez que les outils approuvés à chaque agent, bloquez les actions destructrices comme delete ou deploy, et exigez une approbation pour les appels sensibles, quelle que soit la décision du model.

Isolation des credentials

Les agents s'authentifient auprès de la gateway avec des virtual API keys. Les credentials amont GitHub, Slack ou base de données sont stockés une seule fois dans Odock et injectés uniquement après validation des contrôles de gouvernance.

Coûts et audit sur le trafic d'outils

Tarifez les appels d'outils par requête et par octet, plafonnez-les avec des budgets et des quotas, et attribuez chaque appel à une clé, une équipe et un utilisateur pour la refacturation et les revues de conformité.

Pour aller plus loin
Gateway LLMGuide de gouvernance MCP
Cycle de vie des requêtes MCP

Chaque appel d'outil suit un chemin gouverné

Aucune requête n'atteint un serveur en amont sans passer par l'authentification, les contrôles d'accès, l'inspection et les limites de coût. Chaque résultat est enregistré.

01

Authentifier

Valider la clé API virtuelle.

02

Autoriser

Confirmer les droits d'accès et le scope du serveur.

03

Inspecter & appliquer

Filtrer les outils, les charges utiles et les politiques.

04

Réserver le budget

Vérifier les budgets et quotas avant l'exécution.

05

Transporter

Proxifier en amont via HTTP, SSE ou STDIO.

06

Enregistrer le résultat

Journaliser l'outil, la latence, le statut et le coût.

Exemple de requête bloquéeRefusée par la gouvernance
{
  "apiKey": "vk_agent_prod_support",
  "mcpServer": "github-tools-http",
  "method": "tools/call",
  "tool": "delete_file",
  "reason": "blocked_tool",
  "status": 403
}
Pourquoi c'est essentiel

Les appels d'outils exposent une surface d'attaque différente des appels de modèles

Quand un agent peut écrire dans une base de données, pousser sur GitHub ou déclencher un workflow, la frontière de risque ne se limite plus au prompt. Une passerelle MCP donne aux équipes plateforme et sécurité un point d'application strict sur les actions, pas seulement sur les sorties.

Contrôlez quels outils les agents peuvent atteindre

Autorisez les serveurs MCP connus, exposez uniquement les outils approuvés, et bloquez les actions destructives avant qu'un agent puisse les appeler, indépendamment de ce que le modèle décide.

Appliquez les politiques avant l'exécution

Authentifiez chaque appelant, vérifiez les droits d'accès, inspectez les charges utiles et rejetez les requêtes qui échouent aux règles de sécurité, de budget ou de conformité avant tout appel en amont.

Produisez des preuves prêtes pour l'audit

Attribuez chaque appel d'outil à une clé, une application, une équipe et un utilisateur. Donnez aux équipes sécurité et conformité les enregistrements nécessaires pour auditer le comportement des agents, ou le prouver à un auditeur.

Ce que vous configurez

Une surface de contrôle MCP complète, pas juste un proxy

Odock couvre tout ce dont les équipes platform ont besoin pour opérer les serveurs MCP en production : enregistrement des serveurs, configuration du transport et de l'authentification, gouvernance au niveau des outils, tarification, et enregistrements d'utilisation lisibles par votre équipe sécurité.

Vues MCP
Vue sélectionnée

Enregistrez des serveurs depuis un catalogue de confiance ou ajoutez-les manuellement. Vérifiez le transport, la configuration d'authentification, le scope et le statut d'activation avant qu'un agent puisse y accéder.

catalogue-&-configuration.mcp
En direct
github-tools-http
Catalogue de confiance
TransportSTREAMABLE_HTTP
AuthBEARER
Scopeteam:support
Accès12 clés autorisées
internal-ops-sse
Configuration manuelle
TransportSSE
AuthOAUTH2
ScopeapiKey:vk_ops_prod
Accès1 clé autorisée
filesystem-agent
Configuration manuelle
TransportSTDIO
AuthNONE
Scopeorg-wide
Accès4 clés autorisées
slack-tools-http
Catalogue de confiance
TransportSTREAMABLE_HTTP
AuthBEARER
Scopeteam:success
Accès8 clés autorisées
notion-knowledge-http
Catalogue de confiance
TransportSSE
AuthOAUTH2
ScopeapiKey:vk_product_ai
Accès3 clés autorisées
postgres-ops-stdio
Configuration manuelle
TransportSTDIO
AuthNONE
Scopeorg-wide
Accès2 clés autorisées
Un seul endpoint

Vos agents appellent Odock, pas le serveur en amont

Pointez chaque agent vers `/v1/mcp/{slug}`. Odock authentifie l'appelant, confirme les accès, injecte les credentials en amont, exécute les contrôles de gouvernance et enregistre le résultat. Le serveur en amont ne reçoit jamais de requête non gouvernée.

Ce que le gateway gère

  • Appelez n'importe quel serveur par son slug, sans URL en amont dans le code agent.
  • Clé API virtuelle obligatoire avant qu'un outil soit accessible.
  • Auth en amont injectée après validation des contrôles de gouvernance.
  • HTTP, SSE et STDIO via un seul endpoint gouverné.
mcp_client.py
MCP
Mode
Langage
1
# Utilisez directement l'endpoint MCP d'Odock depuis le client MCP Python officiel
2
import asyncio
3
import os
4
 
5
from mcp import ClientSession
6
from mcp.client.streamable_http import streamable_http_client
7
 
8
async def main():
9
    async with streamable_http_client(
10
        os.environ["ODOCK_MCP_URL"],
11
        headers={"Authorization": f"Bearer {os.environ['ODOCK_API_KEY']}"},
12
    ) as (read_stream, write_stream, _):
13
        async with ClientSession(read_stream, write_stream) as session:
14
            await session.initialize()
15
            result = await session.call_tool("get_me", arguments={})
16
            print(result)
17
 
18
asyncio.run(main())
Règlement IA européen & conformité

Combler le vide d'audit dans vos workflows agents

Les programmes de conformité ont besoin de réponses précises : qui était autorisé à utiliser quel outil, sous quelle politique, avec quelles preuves ? Une couche MCP non gouvernée ne peut pas répondre à ces questions. Odock, si.

  • Faites transiter GitHub, Slack, les bases de données et les outils de workflow internes par un seul endpoint gouverné et auditable
  • Réduisez le risque d'injection de prompt en appliquant les contraintes d'accès aux outils en dehors du runtime agent
  • Produisez des preuves pour les revues IA internes, les évaluations fournisseurs et les programmes de conformité au Règlement IA européen
  • Maintenez le trafic LLM et le trafic d'outils dans la même frontière de politique et d'exploitation
FAQ

Les questions que les équipes posent sur les passerelles MCP

Ce sont les questions récurrentes qui émergent lorsque les équipes passent d'un accès direct aux serveurs MCP à une couche de passerelle gouvernée.

Vos agents ont besoin d'une passerelle, pas juste d'un proxy

Si vos agents peuvent appeler des outils, vous avez besoin du même niveau de contrôle que vous attendez déjà pour le trafic de modèles. Odock gouverne les deux depuis un seul chemin de requête.

Réserver une démoLire le guide de gouvernance MCP
mcp_client.py
# Utilisez directement l'endpoint MCP d'Odock depuis le client MCP Python officielimport asyncioimport os from mcp import ClientSessionfrom mcp.client.streamable_http import streamable_http_client async def main():    async with streamable_http_client(        os.environ["ODOCK_MCP_URL"],        headers={"Authorization": f"Bearer {os.environ['ODOCK_API_KEY']}"},    ) as (read_stream, write_stream, _):        async with ClientSession(read_stream, write_stream) as session:            await session.initialize()            result = await session.call_tool("get_me", arguments={})            print(result) asyncio.run(main())