Hermes Agent で MCP を安全に使うには

こんにちは、Lena です。今週は MCP について書くつもりはありませんでした。しばらく動かしている Hermes Agent のインスタンスに、2つ目のツールサーバーをつなごうとしていただけです。設定を編集して、ツール一覧が更新されるのを見ていた、その途中で手が止まりました。

その agent は、10分前には持っていなかった4つの server にアクセスできるようになっていました。私は、それぞれが何を読むことを許されているのか、ちゃんと考えていませんでした。ドキュメントに戻りました。それから config に戻りました。今回の導入はここで止めておきます — というのも、この小さな一時停止こそが、この記事全体の話だからです。

これは MCP の入門ではありません。ここまで読んでいるなら、この protocol が何かはたぶんもう知っているはずです。私が書き留めておきたいのは、Hermes Agent で MCP を使うときに、意図していた以上の権限を agent にこっそり渡さないために、最近学んでいることです。

MCP は実際に Hermes Agent に何を足すのか

Hermes ネイティブツールを書かずに外部ツールへアクセスする

Hermes には固定された組み込み機能のセットがあります。MCP は、新しいネイティブツールを書かずに、そのセットを拡張するための方法です。 Hermes に server を指定します。ローカルでもリモートでも構いません。すると、その server のツール一覧が組み込みツールの横に現れます。agent から見ると、ほとんど違いはありません。

ただ、この「ほとんど」が大事です。組み込みツールは Hermes 自身の権限モデルの中にあります。一方、MCP tools は protocol の境界の向こう側にあります。実際にあなたのマシンやネットワーク上で何をするかは、信頼した server に完全に依存します。

なぜ MCP は魔法の機能ではなく、adapter layer なのか

私は何度もこの点を自分に言い聞かせています。MCP は、ツールを自動的に安全にするわけでも、賢くするわけでもありません。標準化しているのは、ツールが agent にどう説明されるか、そして call と response が JSON-RPC 2.0 の上をどう行き来するかです。それだけです。

だから Hermes で MCP tool に何か問題が起きたとき、バグはほとんどの場合 MCP そのものにはありません。接続した server、そこで使われている credentials、あるいは「agent が正しい呼び出しを判断してくれるはず」という前提にあります。これは、私は二度学んでようやく覚えました。

MCP を使うべきとき、使わないほうがいいとき

向いているケース、向いていないケース、広げすぎたツール面

Hermes setup の中で、MCP が本当に役に立つ場面はこんなものです。

外部システムに対する読み取り中心の作業 — issues を取得する、logs を問い合わせる、docs を読む、agent がネイティブには届かない files を見る。
すでに信頼している internal APIs を、自分で管理する小さな MCP server で包む。
一度きりの integrations。Hermes ネイティブツールを書くほどではないものです。

一方で、私は次のような場合は立ち止まります。

production systems に破壊的な操作をするもの。 Deletes、force-pushes、schema changes。tool description が十分に自信ありげに書かれていれば、agent は平気で呼び出します。
一度に何十個もの tools を公開する servers。 Anthropic のエンジニアリングチームは、ほとんどの MCP clients がすべての tool definitions をあらかじめモデルの context に読み込むため、接続する servers が増えるほど tokens も surface area も増え、tool description が静かに振る舞いを形作る場所も増えると指摘しています。研究者たちも別に、tool descriptions 自体が LLM に渡され、隠れた指示を含み得ること — いま広く tool poisoning と呼ばれている問題 — を記録しています。窓が大きければ、入ってくる風も大きくなります。
ランダムな community servers。特に広い credentials を求めるものです。MongoDB チームは docs でかなり直接的に書いています。Streamable HTTP servers はデフォルトで localhost (127.0.0.1) にバインドすべきで、0.0.0.0 にバインドするとローカルネットワーク全体に露出するからです。多くの「とりあえず動く」tutorials は、この部分を飛ばします。

workflow がまれで、sensitive で、短命なら、MCP はたぶん正しい形ではありません。 script として作り、明示的に呼び出すほうがはっきりします。

Hermes で MCP を安全に設定する

stdio と remote servers

transport は2つあります。交換可能ではありません。

Stdio は、MCP server をあなたのマシン上の child process として起動します。Hermes は stdin/stdout 経由で話します。シンプルで低レイテンシです。local filesystem や developer tooling のような用途には向いています。トレードオフは、あなた自身のマシン上で binary を実行していることです。そして OAuth/token の仕組みは、ここではあまり効きません。

Remote (Streamable HTTP) は、server をどこか別の場所で動かし、HTTP で通信します。ここでは authorization がようやく実質を持ちます。公式 MCP specification によれば、このモードの MCP servers はいま OAuth Resource Servers として分類されます。つまり tokens には明確な scope と audience があり、汎用の API key ではありません。2025年11月の spec がなぜここまで強くこの点を押しているのか、少し分かってきた気がします。単一の静的 API key は、あらゆる問題の最悪版を静かに作っていたのです。

私が何度も戻ってくる大まかなルールはこれです。本当にローカルである必要があるものには stdio を使い、本物のネットワークサービスと話すものには remote を使う。 同じ Hermes config の中で両方を混ぜるのは問題ありません。ただ、私はどちらがどちらか忘れないように、はっきりラベルを付けます。

server ごとのフィルタリング、env の分離、/reload-mcp workflow

実際に時間を節約してくれた習慣が3つあります。

server ごとにツール面を絞る。 server が20個の tools を公開していて、agent が必要とするのが3個だけなら、残り17個は読み込まない。Hermes では server ごとに tool names を allowlist できます。これは被害妄想ではありません。前に触れた prompt-injection surface を直接小さくします。
environment variables を分離する。 起動するすべての MCP server に、あなたの shell environment 全体を渡さないこと。その server が本当に必要とする variables だけを渡します。secrets は hardcode せず、たとえば "GITHUB_TOKEN": "$GITHUB_TOKEN" のように expansion で参照します。他の agent runtimes は、MCP processes を起動する前に、TOKEN、SECRET、PASSWORD のような patterns に一致する variables を自動的に redact します — でも Hermes はデフォルトではこれをしてくれません。だから明示する必要があります。
/reload-mcp は意識して使う。反射的に使わない。 server config を変えたら reload します。ただし作業を続ける前に、新しい tool list を確認します。reload は、「agent がいま何にアクセスできるのか」を自然に読み直せる唯一のタイミングです。考えすぎかもしれませんが、この確認を飛ばすと、silent privilege creep が起きます。

日常で実際にうまくいく MCP パターン

GitHub、databases、internal APIs、browser stacks

いくつか、実際に持ちこたえているパターンがあります。

GitHub-style read access。 scoped fine-grained tokens を使います。agent は issues、PRs、code を読めますが、push や merge はできません。書き込みは人間を通します。

Databases。 read replicas のみ。それでも、query timeouts は短く、result-row caps は低くします。agents が偶然重い queries を書くのは、理論上のリスクではなく、実際の failure mode です。

Internal APIs。 小さな in-house MCP server で包みます。master service-account token を使い回さないこと。agent 専用に、より狭い token を発行します。MCP を大規模に観察している実務家たちは、現実の MCP servers のかなりの割合が API keys や PATs のような long-lived static secrets に依存しており、それこそが最も漏れやすいパターンだと指摘しています。その数字が、私はずっと頭に残っています。

Browser stacks。 これは blast radius が最も大きい integration です。browser MCP server は navigate し、click し、forms を submit できます。私は積極的に必要なとき以外は off にし、使い終わったらまた off にします。

この全体を貫いている線は、least privilege は agent ごとではなく、server ごとに考えるということです。各 MCP server は、別々の trust decision です。

Hermes でよくある MCP の間違い

安全でない defaults、大きすぎるツール面、古い config assumptions

自分でやってしまったこと、あるいは他の人がやっているのを見たことです。

「default config」は「safe config」だと信じる。 たいてい、それは「demo しやすい config」という意味です。blog post から copy-paste したものは、この文章のものも含めて audit する価値があります。defaults は最短経路のために書かれていて、最も安全な経路のためではありません。
先につなぎ、あとで scope する。 正直に言うと、あとで scope するというのは、だいたい永遠に scope しないということです。server を追加する時点で scopes を設定します。
tool description が tool の実際の動作だと思い込む。 Tool descriptions はpromptsです。agent の context に入り、振る舞いを形作ります。poisoned な、あるいは雑に書かれた description は、ユーザーには見えない形で outcome をずらすことがあります。
config drift の存在を忘れる。 先月は安全だった server が、今月は tool list を更新しているかもしれません。Reload, re-read, re-decide.

最後の点をどう自動化すればいいのか、私はまだ完全には分かっていません。たぶん、また戻ってくる価値があります。

FAQ

Hermes にすでに使える tools があるなら、MCP は必要ですか？

いいえ。実際の gap があるときだけ MCP を足します。新しい servers は、使うかどうかに関係なく surface area を増やします。

Stdio と remote、どちらが「より安全」ですか？

問いが違います。Stdio はローカルで binary を動かします。remote はネットワークを越えます。脅威が違います。data と credentials が実際にどこにあるかで選びます。

公式の MCP server なら、そのまま信頼していいですか？

「公式」とは vendor が書いたという意味です。あなたが与えた configuration が安全だという意味ではありません。scope と tokens は、まだあなたの責任です。

MCP configs はどれくらいの頻度で見直すべきですか？

server を追加、削除、更新したときは毎回です。それに、何も変えていなくても月に一度は軽く見ます。

私はたぶん、この進化をもう少し見続けると思います。protocol はまだ動いていて、spec はまだ締まってきています。いま明白に見える patterns が、半年後には naive に見えるかもしれません。今のところ、私にとって一番役に立っているのは config snippet ではありません。tool list が増えたときに、少し立ち止まる習慣です。今回はここまでにしておきます。