Agentomy MCP Gateway

規制対象企業におけるAIエージェントのためのガバナンス層である Agentomy のオープンな構成要素です。その他は github.com/getagentomy でご覧いただけます。

エージェントとサーバーの間に位置することで、あらゆる stdio MCP サーバーを統制します。すべての tools/call はサーバーに到達する前にポリシーに対してチェックされます。拒否はゲートウェイが応答し、転送されることはないため、副作用は発生しません。

上流サーバーについては何も変更されません。パッチもフォークもされず、統制されていることを知ることもありません。

観察ではなく介在する理由

MCP トラフィックを監視して報告するサイドカーは、止められなかったものの記録を生み出します。回線上に位置することが、報告を拒否に変えるのです。

Related MCP server: Dmint MCP Proxy

インストールと実行

# Instead of launching the MCP server directly:
#   my-mcp-server --flag
# launch it through the gateway:
AGENTOMY_ENDPOINT=https://your-agentomy \
AGENTOMY_API_KEY=... \
  agentomy-mcp-gateway, my-mcp-server --flag

エージェントの MCP 設定で、サーバーの command と args を置き換えます:

{
  "mcpServers": {
    "dev-tools": {
      "command": "agentomy-mcp-gateway",
      "args": ["--", "the-original-command", "--its", "--flags"],
      "env": { "AGENTOMY_ENDPOINT": "https://your-agentomy", "AGENTOMY_API_KEY": "..." }
    }
  }
}

これが統合のすべてです。オペレーターによる、エージェントごとの設定変更1つだけです。

プロトコルへの影響

リクエストは到着順に判定されます。並行して判定すると、先の呼び出しが解決される前に後の呼び出しがサーバーに到達してしまう可能性があり、これは負荷がかかったときだけ現れる並び替えバグです。

フェイルクローズ、そしてその代償

すべての障害経路は拒否します:

正直なトレードオフ: プラットフォームがダウンすると、統制対象のツールは動作を停止します。 これはガバナンスコンポーネントとして正しい動作であり、実際の可用性の結合です。それに応じてプラットフォームを運用してください。

理由は意図的に区別されています。governance_unreachable を見たオペレーターは障害を抱えており、policy_denied を見たオペレーターはポリシーの問題を抱えています。これらを「拒否」にまとめてしまうと、違いが重要になるまさにその瞬間に、両者を区別できなくなります。

authorized フィールドが欠けている場合は、真偽値として読むのではなく拒否します。真偽値チェックは、エラーオブジェクトを含む予期しないペイロードをすべて許可に変えてしまうからです。

行わないこと

アクションを統制し、ディスカバリーは統制しません。tools/list は通過します。エージェントが見るものを狭めながら、行うことを統制しないままにするのは、間違った場所での見せかけにすぎません。

結果を書き換えません。ゲートウェイはリクエストを判定します。応答を編集させることは、ゲートウェイを会話の門ではなく参加者にしてしまいます。

引数を意味的に検査しません。ポリシーにはツール名と引数のキーが渡され、値は渡されません。引数レベルのポリシーはプラットフォームの関心事であり、完全な引数値を判定エンドポイントに送信すると、ファイルの内容やシェルコマンドが別のシステムに入ってしまいます。

ライセンス

Apache-2.0.