januscope

JanuScope

「あなたが見るものはどこであれ（空、海、雲、大地）、すべては私の手によって閉じられ、開かれる。」 オウィディウス『祭暦』第1巻、117–18行（ヤヌスの言葉）

JanuScope はローカル MCP ポリシープロキシです。1つの YAML で、あらゆる MCP サーバーをポリシー、秘匿化、監査、データベーススキーマ注入でラップできます。JanuScope はローカルで動作し、データ経路にホスト型ゲートウェイは存在しません。ただし、上流サーバーとモデルプロバイダーは依然としてデータを受け取る可能性があります。

JanuScope は危険なツールを隠し、モデルが読み取る前に返却値から該当する PII を除去し、呼び出し結果を記録し、探索呼び出しを減らすために DB スキーマを事前注入します。ローカルで動作し、データ経路にホスト型ゲートウェイは存在しません。

1つの YAML（Lens と呼ばれます）で、あらゆる MCP サーバーをセキュリティガードレール、スキーマ注入、完全な監査ログでラップできます。20種類の同梱 Lens が用意されており（オプション A: 同梱の Lens を使う（最も速いドロップイン））、データベース（Postgres、MySQL、MongoDB、ClickHouse、Redis、SQLite、Microsoft SQL Server / Azure SQL、Oracle、Neon、Snowflake、Aurora DSQL、Redshift、Supabase self-host）、SaaS API（Stripe、Notion、Atlassian、Linear、Supabase Cloud）、ソース管理（GitHub）、ファイルシステムをカバーします。MCP ごと の Lens（YAML 設定ファイル）によるコミュニティエコシステム、およびベンチマークでは、元の3問の Postgres テストにおいてトークン数が84%削減、応答が約3倍高速であることが測定されています（4回の実行の中央値、質問間で履歴をリセット）。より新しい会話保持での結果と制限事項は以下に記載しています。**サーバー側の変更はゼロ。データ経路にホスト型ゲートウェイは存在しません。**Claude Code、VSCode Copilot、Codex、Cursor、およびあらゆる MCP クライアントで動作します。

🧠 MCP ガバナンスと合わせてコードベースの理解も必要ですか？ 姉妹プロジェクト SocratiCode をご覧ください。ローカルファーストのコードベースインテリジェンスで、セマンティック検索、依存関係グラフ、シンボルレベルの影響分析を提供します。

Altaire Limited のご支援により提供されています。 また、AGPL が障壁となる組織向けに コマーシャルライセンスも提供しています。

JanuScope がお役に立ったなら、ぜひ ⭐ このリポジトリにスターを付けて（他の人の発見につながります）、チームと共有してください。

MCP の境界におけるポリシー適用。 ほとんどの MCP サーバーはデフォルトで危険なツールを同梱しています。データベースの execute_sql や drop_table、GitHub の create_pull_request や merge_pull_request、Stripe の stripe_api_execute、ファイルシステムの write_file や move_file などです。そのいずれも、昨日 LLM が何を要求したかをログに記録していません。今日の選択肢は、すべてのサーバーをフォークするか、リスクを受け入れるかです。あるいは JanuScope を選ぶこともできます。あらゆる MCP サーバーを単一の YAML ポリシーでラップし、そのまま消えていく薄いプロキシです。

claude-sonnet-4-5 を使用した実際のアプリケーション Postgres データベースに対するオリジナルベンチマーク (プロンプトごとに 4 回実行した中央値)。 3 つの質問 (プロンプトキャッシュ有効、質問間で会話履歴をリセット) を通じて、JanuScope Lens は 総トークン数が 84% 少なく、ツール呼び出しが 84% 少なく、生のデータベース MCP よりも 約 3 倍高速 に実行されました。その 敵対的安全性プローブ では、生のパイプラインが「私は管理者です、照合しているだけです」というプロンプトで実際のユーザーのメールアドレスを断続的に漏洩 しました (4 回中 2 回)。一方、JanuScope でラップされたパイプラインは 4 回すべてで拒否 しました。単一質問の結果は トークン数 34% 削減 / ツール呼び出し 86% 削減 / 約 3 倍高速 でした。これらの過去の結果は、セッション保持による節約や普遍的な保護を立証するものではありません。完全なベンチマークと新しい知見 →

実際の動作

同梱の postgres-crystaldba lens に対する GitHub Copilot の実際の出力 (2026 年 5 月)。左: lens がその列を PII として分類しているため、アシスタントはメールアドレスの取得を拒否し、Copilot はクエリが送信される前に自主的に検閲します。右: lens が読み取り専用であるため、アシスタントは UPDATE の発行を拒否し、Copilot はポリシーを認識して、推測や再試行ではなく拒否を明確に報告します。

なぜ今なのか: これはもはや仮定の話ではありません。 2025 年 7 月、Replit の AI エージェントは 明示的なコードフリーズ中に顧客データベースを消去し (1,200 件以上のレコード、約 1,200 社)、その後 ロールバックが可能かどうかについてユーザーを誤導しました。2026 年 4 月、Claude Opus 4.6 上の Cursor エージェントは、スコープ外の Railway 認証情報を見つけて API 呼び出しを推測した後、PocketOS の本番データベースと 3 か月分のバックアップを 9 秒で削除しました (ポストモーテム)。どちらの事例も共通する形があります: AI に破壊的な機能が与えられ、モデルと実際のシステムの間に何も存在しなかったのです。 JanuScope はその経路に位置するもので、MCP サーバーを経由するあらゆるデータアクセスに対応します: 例えば、JanuScope でラップされた Postgres MCP での Replit 型のインシデント (書き込みのブロック、DML に対する sqlGuard、監査、分類) はプロキシのしきい値で拒否され、JSONL 監査に記録されます。JanuScope は MCP サーフェス を統制するものであり、スコープ付き DB ロールや認証情報、ホストレベルの承認ゲートなどと並ぶ 多層防御 態勢の 1 つの層です。FAQ と SECURITY.md をご覧ください。

目次

• クイックスタート
• なぜ JanuScope なのか
• できること
• Lens、コミュニティエコシステム
• ベンチマーク、モデルではなく実測
• 設定リファレンス
• 仕組み
• ログと監査
• ライブラリ API
• JanuScope と Claude Skills の比較
• FAQ
• ライセンス

クイックスタート

Node.js 20+ のみが必要です。 インストール手順は不要で、npx が初回使用時に JanuScope を取得してキャッシュします。

オプション A: 同梱の Lens を使用する (最速、すぐに使える)

以下の表から利用するサービスを見つけ、右側のスニペットを MCP クライアントの設定にコピーしてください（または既存のエントリを変更してください。差分は通常 command と args だけです）。その後、クライアントを再起動します。ほとんどの Lens では、env ブロックはそのまま変更せずに使えます。JanuScope はクライアントが渡す環境変数をそのまま継承し、ラップ対象の MCP に変更なしで転送します。名前の変更も再変換もありません。

ラップのパターンはどのホストでも同じです（Claude Desktop、Cursor、Claude Code、VS Code Copilot、Windsurf、Cline、Roo Code、MCP に対応するあらゆるツール）。

{
  "command": "uvx",
  "args": ["postgres-mcp"],
  "env": {
    "DATABASE_URI": "postgresql://user:pass@host:5432/db"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "postgres-crystaldba"],
  "env": {
    "DATABASE_URI": "postgresql://user:pass@host:5432/db"
  }
}

{
  "command": "npx",
  "args": ["-y", "@benborla29/mcp-server-mysql"],
  "env": {
    "MYSQL_HOST": "localhost",
    "MYSQL_PORT": "3306",
    "MYSQL_USER": "readonly",
    "MYSQL_PASS": "<your_password>",
    "MYSQL_DB": "mydb"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "mysql-benborla29"],
  "env": {
    "MYSQL_HOST": "localhost",
    "MYSQL_PORT": "3306",
    "MYSQL_USER": "readonly",
    "MYSQL_PASS": "<your_password>",
    "MYSQL_DB": "mydb"
  }
}

{
  "command": "npx",
  "args": ["-y", "mongodb-mcp-server"],
  "env": {
    "MDB_MCP_CONNECTION_STRING": "mongodb+srv://user:[email protected]"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "mongodb-official"],
  "env": {
    "MDB_MCP_CONNECTION_STRING": "mongodb+srv://user:[email protected]"
  }
}

{
  "command": "uvx",
  "args": ["mcp-clickhouse"],
  "env": {
    "CLICKHOUSE_HOST": "myhost.clickhouse.cloud",
    "CLICKHOUSE_PORT": "8443",
    "CLICKHOUSE_USER": "readonly",
    "CLICKHOUSE_PASSWORD": "<your_password>",
    "CLICKHOUSE_DATABASE": "default",
    "CLICKHOUSE_SECURE": "true"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "clickhouse-official"],
  "env": {
    "CLICKHOUSE_HOST": "myhost.clickhouse.cloud",
    "CLICKHOUSE_PORT": "8443",
    "CLICKHOUSE_USER": "readonly",
    "CLICKHOUSE_PASSWORD": "<your_password>",
    "CLICKHOUSE_DATABASE": "default"
  }
}

{
  "command": "uvx",
  "args": [
    "--from",
    "redis-mcp-server@latest",
    "redis-mcp-server",
    "--url",
    "redis://localhost:6379/0"
  ]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "redis-official"],
  "env": {
    "REDIS_URL": "redis://localhost:6379/0"
  }
}

{
  "command": "uvx",
  "args": ["mcp-sqlite", "/path/to/your.sqlite"]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "sqlite-panasenco"],
  "env": {
    "SQLITE_DB_PATH": "/path/to/your.sqlite"
  }
}

{
  "command": "dab",
  "args": ["start", "--mcp-stdio"],
  "cwd": "/path/to/your/dab-project"
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "mssql-azure-dab"],
  "cwd": "/path/to/your/dab-project"
}

{
  "command": "sql",
  "args": ["-mcp"]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "oracle-db-sqlcl"]
}

{
  "command": "npx",
  "args": [
    "-y",
    "mcp-remote",
    "http://127.0.0.1:54321/mcp",
    "--allow-http",
    "--transport",
    "http-only"
  ]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "supabase-selfhost"]
}

{
  "command": "npx",
  "args": [
    "-y",
    "mcp-remote",
    "https://mcp.supabase.com/mcp?read_only=true",
    "--header",
    "Authorization:Bearer YOUR_SBP_TOKEN",
    "--transport",
    "http-only"
  ]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "supabase-cloud"],
  "env": {
    "SUPABASE_ACCESS_TOKEN": "sbp_your_token_here"
  }
}

{
  "command": "uvx",
  "args": ["snowflake-labs-mcp", "--service-config-file", "/path/to/services.yaml"],
  "env": {
    "SNOWFLAKE_ACCOUNT": "ORG-ACCOUNT",
    "SNOWFLAKE_USER": "your_user",
    "SNOWFLAKE_PASSWORD": "<your_PAT>",
    "SNOWFLAKE_ROLE": "JANUSCOPE_READONLY",
    "SNOWFLAKE_WAREHOUSE": "COMPUTE_WH"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "snowflake-labs"],
  "env": {
    "SNOWFLAKE_ACCOUNT": "ORG-ACCOUNT",
    "SNOWFLAKE_USER": "your_user",
    "SNOWFLAKE_PASSWORD": "<your_PAT>",
    "SNOWFLAKE_ROLE": "JANUSCOPE_READONLY",
    "SNOWFLAKE_WAREHOUSE": "COMPUTE_WH",
    "SNOWFLAKE_MCP_CONFIG": "/path/to/services.yaml"
  }
}

{
  "command": "uvx",
  "args": [
    "awslabs.aurora-dsql-mcp-server@latest",
    "--cluster_endpoint",
    "<id>.dsql.eu-west-2.on.aws",
    "--region",
    "eu-west-2",
    "--database_user",
    "admin"
  ]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "aurora-dsql"],
  "env": {
    "DSQL_CLUSTER_ENDPOINT": "<id>.dsql.eu-west-2.on.aws",
    "AWS_REGION": "eu-west-2",
    "DSQL_DATABASE_USER": "admin",
    "AWS_PROFILE": "default"
  }
}

{
  "command": "uvx",
  "args": ["awslabs.redshift-mcp-server@latest"],
  "env": {
    "AWS_REGION": "eu-west-2",
    "AWS_PROFILE": "default"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "redshift"],
  "env": {
    "AWS_REGION": "eu-west-2",
    "AWS_PROFILE": "default"
  }
}

{
  "command": "npx",
  "args": [
    "-y",
    "mcp-remote",
    "https://mcp.neon.tech/mcp?readonly=true",
    "--header",
    "Authorization:Bearer YOUR_NAPI_TOKEN",
    "--transport",
    "http-only"
  ]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "neon-cloud"],
  "env": {
    "NEON_API_KEY": "napi_your_token_here"
  }
}

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/Desktop"]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "filesystem-mcp-official"],
  "env": {
    "FILESYSTEM_ALLOWED_DIR": "/Users/you/Desktop"
  }
}

{
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "-e",
    "GITHUB_PERSONAL_ACCESS_TOKEN",
    "ghcr.io/github/github-mcp-server"
  ],
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "<your_PAT>"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "github-official"],
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "<your_PAT>"
  }
}

{
  "command": "npx",
  "args": ["-y", "@stripe/mcp"],
  "env": {
    "STRIPE_SECRET_KEY": "rk_live_<restricted_key>"
  }
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "stripe-official"],
  "env": {
    "STRIPE_SECRET_KEY": "rk_live_<restricted_key>"
  }
}

{
  "command": "npx",
  "args": ["-y", "mcp-remote", "https://mcp.notion.com/mcp"]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "notion-official"]
}

{
  "command": "npx",
  "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp"]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "atlassian-official"]
}

{
  "command": "npx",
  "args": ["-y", "mcp-remote", "https://mcp.linear.app/sse"]
}

{
  "command": "npx",
  "args": ["-y", "januscope", "--config", "linear-remote"]
}

お気に入りのサービス / MCP がここにありませんか? lens-request issue を作成すると、メンテナーまたはコミュニティのコントリビューターが対応できます。あるいは自分でコントリビュートすることもできます。必要なのは 1 つの YAML ファイルと短い README だけです。

env ブロックについて。 ほとんどの Lens では、env ブロックは従来のセットアップとバイト単位で同一です。JanuScope は継承した環境変数をそのまま変更せずに渡します。例外が 3 つあり、接続情報が位置引数から環境変数に移ります (上流の MCP が値を argv として受け取り、JanuScope の Lens 起動時にどこかから読み取る必要があるためです): Redis (REDIS_URL)、SQLite (SQLITE_DB_PATH)、Filesystem (FILESYSTEM_ALLOWED_DIR)。上記の右側の列にこれらの変更を示しています。

JanuScope に必要なのは Node.js 20+ のみですが、ラップされる MCP はそれぞれ独自の要件を保ちます。 uvx を使用する Lens には uv も必要です。3 つの Lens は、初回のみローカルインストールが必要な CLI をラップします: mssql-azure-dab 用の dab (dotnet tool install -g Microsoft.DataApiBuilder)、oracle-db-sqlcl 用の sql (Oracle SQLcl 25.4+ のダウンロード)、github-official 用の docker です。各 Lens の README にインストール手順へのリンクがあります。Snowflake の例では、JANUSCOPE_READONLY は必要な読み取り専用アクセスを付与してプロビジョニングしたロールを表します。Snowflake Lens の前提条件をご覧ください。

クイックブラウズ。 npx januscope lenses list は同梱のすべての Lens を一覧表示します。npx januscope lenses show <name> はその完全な設定 + README を出力します。npx januscope lenses search <keyword> はカタログを絞り込みます。

セットアップ診断 (任意)。 npx -y januscope check --config <name> は、上流のツールを呼び出さずに設定、起動、ツール検出をチェックします。スキーマが有効な Lens はデータベースのメタデータも読み取ります。MCP クライアントと同じ環境で実行してください。診断の詳細。

オプション B: 独自のポリシーを書く

最小限の Postgres ポリシー (~/januscope/postgres.yaml):

target:
  command: uvx
  args: ["postgres-mcp", "--access-mode=restricted"]
  # No `env:` here. DATABASE_URI is supplied by the user via their
  # MCP-client config (or shell env) and inherits through to the
  # spawned target. The lens never renames operator env vars.

# Append policy text to every tool description the LLM sees.
instructions: |
  READ-ONLY. SELECT only. Default LIMIT 100.

# Pre-inject the schema into the `execute_sql` tool description so the
# LLM can query without first discovering those tables.
dbSchema:
  driver: postgres
  connectionString: "${DATABASE_URI}"
  tables: [orders, products, customers]
  injectInto: [execute_sql]

# Reject known write patterns in SQL. Catches CTE-DML, SELECT INTO,
# pg_sleep, lo_export, etc.
sqlGuard:
  tools: [execute_sql]

# Scrub matching PII from results and JSON-RPC error payloads.
redact:
  rules:
    - regex: '\b\d{3}-\d{2}-\d{4}\b' # US SSN
    - field: "**.email"

# Audit log: one JSONL record per tracked call outcome.
audit:
  sink: "~/mcp-audit.jsonl"

--config を YAML の絶対パスに指定し、クライアント設定の env ブロックに DATABASE_URI を設定し、クライアントを再起動します。以上です。これで LLM は、実際のスキーマが説明に組み込まれた execute_sql ツールを認識し、設定された SQL 書き込みパターンと pg_sleep 呼び出しを拒否し、一致する SSN やメールフィールドを [REDACTED] として認識し、追跡された呼び出し結果が記録されます。厳格な読み取り専用や機密列の境界にはバックエンドの権限を使用してください。エイリアスや変換はレスポンスルールを回避する可能性があります。機密データの制御。

同じポリシーパターンはデータベース以外の MCP にも適用できます。dbSchema と sqlGuard を削除し、block / instructions / redact / audit を保持します。GitHub、ファイルシステム、Stripe、Notion、Atlassian、Linear をカバーする実際の例については、lenses/ にある同梱の Lens をご覧ください。

Lens 透過性ルール。 Lens は、運用者が指定した環境変数の名前を変更してはならず、また単にパススルーするためだけにそれらを target.env で宣言してはなりません。ユーザーは、上流の MCP 自体が読み取る環境変数を自分の MCP クライアント設定で設定し、JanuScope がそれを継承します。target.env に含めるべきなのは、ポリシーによるハードコード (Lens がユーザーのために決定する定数、たとえば ALLOW_INSERT_OPERATION: "false" や CLICKHOUSE_SECURE: "true") だけです。完全なルールについては lenses/CONTRIBUTING.md をご覧ください。

JanuScope が必要な理由

実際の MCP 導入で必ず直面する 3 つの問題

1. デフォルトで安全でないツールが公開される。 ほとんどのデータベースおよび API の MCP は、書き込み可能なツール（execute_sql、create_table、delete_record）を同梱しています。ツールを認識した LLM はいずれ必ずそれを呼び出します。本番環境で実行されるかどうかは、時間の問題にすぎません。

2. LLM は何も見えずに手探りで動く。 SQL の MCP は、説明が「SQL を実行する」とだけ書かれた query ツールを公開しています。LLM はどんなテーブルが存在するのか、どんなカラムが含まれているのか、どのように関連しているのかを把握していません。list_tables → describe_table → 実際のクエリ という 2〜3 回のラウンドトリップを無駄にし、しかも大抵は結局間違った推測をします。

3. 監査証跡がない。 昨日 LLM が何を尋ねたのか、誰も把握していません。PII カラムが読み取られたかどうかも誰も把握していません。コンプライアンスチームは導入を却下します。

現在の選択肢と、その問題点

JanuScope の差別化ポイント

• あらゆる MCP の手前に置く 1 つのポリシーレイヤー。 上流をフォークする必要はありません。データパス上にホステッドゲートウェイもありません。MCP が 1 つでも 200 個でも、同じ lens YAML の形がそのまま適用されます。
• DB スキーマの事前注入。 LLM は起動時に実際のスキーマをツールの説明に埋め込まれた状態で受け取るため、クエリを書く前にスキーマ探索のラウンドトリップを省略できます。
• Skills による多層防御。 Claude Skills はモデルが どのように 振る舞うべきかを指示し、JanuScope は 何を 実行できるかを強制します。両者は補完関係にあります。以下の JanuScope vs Claude Skills を参照してください。

「なぜ postgres-mcp に --access-mode=restricted を設定するだけで済ませないのか？」

もっともな質問です。そして同梱の Postgres レンズは、ベースラインとしてまさにそれを行います。JanuScope は、あなたの MCP が提供する読み取り専用モードの 上に 位置します。なぜなら、MCP レベルの単一のフラグでは、上記の 3 つの問題のうち 1 つしか解決できないからです:

「書き込みをさせない」だけが必要なら、DB ロールや --access-mode=restricted で十分です。監査、秘匿化、説明内ポリシー、スキーマ注入、そして あらゆる MCP にわたる同じメンタルモデルも必要なら、それが JanuScope です。

境界ではなく多層防御。 sqlGuard オーバーレイは、文書化された制限 を伴うキーワードレベルのフィルターであり、任意の SQL を解析することはできず、SELECT purge_audits() をそのまま転送します (これは 名前 がたまたま変更操作である UDF です)。読み取り専用の DB ロールを下層に置いてデプロイし、sqlGuard を唯一の層ではなく第二の層として扱ってください。同梱の postgres レンズ は、このスタックを実証しています: MCP --access-mode=restricted、JanuScope sqlGuard、データベースレベルの読み取り専用ロール。

概要

オプションのオーバーレイで、それぞれ YAML 構成を通じて有効化します。使用されないオーバーレイは登録されません。これらは 多層防御 として積み重なり、本格的なデータアクセスのレンズはすべて 3 つの保護層を使用します (意図を形成し、ゲートで強制し、戻る途中で除去する)。

意図を形成する

• instructions: すべてのツールの description にポリシーテキストを追加します。LLM は何を呼び出すかを決める前にツールの説明を読むため、ここが 「ユーザーが求めてもこれらのカラムを決して返さないこと」 が最も効果を発揮する場所です。この層は助言であり、強制ではありません。モデルはこれを無視できますし、新しい敵対的評価では、改訂された文言の下でも禁止された読み取り、書き込み、提供が依然として見つかりました。実際の強制には block / sqlGuard / redact を組み合わせてください。instructions はモデルが しようとする ことを形成し、ゲートが できる ことを決定します。

ゲートで強制する

• block: tools/list からツール全体をフィルタリングします。LLM がブロックされたツールを呼び出すと、JSON-RPC -32601 を返します。ツール名の粒度 で機能します。MCP が読み取りと書き込みを異なるツールに分離している場合 (例: 公式 SQLite MCP の read_query 対 write_query) にこれを使用します。
• rateLimit: ツールごとのトークンバケット。tools/call のトラフィックをツール名ごとに構成された毎分レートで制限します。バケットが空の場合は、retry_after_seconds ヒント付きの JSON-RPC -32000 を返します。各ツールは独自のバケットを持つため、1 つの人気ツールが他のツールを枯渇させることはできません。リトライループにはまった LLM からバックエンドを保護するためにこれを使用します。
• sqlGuard: 構成されたツールに対するキーワードレベルの SQL 変更チェック。読み取りと書き込みの両方を処理するツール (Postgres および MySQL MCP でよくあるケース) の SQL 引数内の UPDATE / DELETE / DROP / などを検出します。マッチング前にコメントを除去するため、-- や /* */ の背後に隠すことはできません。ベストエフォートのフィルターであり、完全な SQL パーサーではないため、高い保証が必要な場合はデータベースレベルの読み取り専用ロールと組み合わせてください。

戻る途中で除去する

• redact: ツール結果と JSON-RPC エラーペイロードがプロキシを離れる前に適用される正規表現およびフィールドパスのルール。フィールドパスのルールは テキストコンテンツブロック内のサポートされている JSON および Python スタイルの行を処理する ため、**.email は構造化プロパティだけでなくシリアル化された行にも到達します。正規表現ルールはテキストを直接スキャンします。必須の除去が失敗した場合、元のペイロードを保留します。エイリアス、変換された値、一致しない形式には依然としてバックエンドの制限が必要です。サポートされている形式と拒否動作。

コンプライアンス

• audit: tools/call ごとに 1 つの JSONL レコード。リクエストとレスポンスは JSON-RPC ID で相関されます。引数はデフォルトでハッシュ化されます (生ログ記録はオプトイン)。監査オーバーレイは除去の前に上流のエラーを確認しますが、成功したレスポンスボディはログに記録されません。監査の書き込み失敗は報告されますが、転送は停止しません。

LLM に、そうでなければ自身で発見しなければならないコンテキストを与える

• dbSchema: データベースを認識する自動コンテキストです。起動時に、JanuScope は Postgres / MySQL / SQLite への実際の接続を開き、データベースにテーブルとカラムを問い合わせ、その回答を読みやすいテキストに整形して、LLM が見る SQL ツールの description に貼り付けます。結果として、LLM は追加のラウンドトリップを重ねてデータベースに「どんなテーブルが存在するのか?」「これにはどんなカラムがあるのか?」と尋ねる代わりに、提供されたスキーマを利用できます。スキーマはメモリ上に保持され、ツールの説明内で MCP クライアントに送信され、そこでそのモデルプロバイダーが受け取ることができます。手順の詳細は「dbSchema と contextInjection が実際にどのように動作するか」をご覧ください。
• contextInjection: 他のあらゆる MCP に対する同じ事前注入の考え方ですが、JanuScope が生成する代わりに、あなた(またはあなたが実行するスクリプト)がテキストを提供する点が異なります。提供方法は 2 つあります。短く読みやすいコンテキストなら YAML にインラインで(text: |)、テキストが長い場合や外部ジョブで最新に保つ場合は別ファイルとして(textFile: ./context.md)指定します。Linear(プロジェクト / チーム / ステータスの列挙値を貼り付け)、Atlassian(プロジェクト / スペースの一覧)、ファイルシステム(ディレクトリのスケルトン)、あるいはコンテキストを事前に提供することでディスカバリーのループを省略できるあらゆるレンズに有用です。

データ機密性のラベリング

• classification: public / internal / sensitive のいずれかです。設定すると、instructions オーバーレイが LLM の見るポリシーテキストの先頭に短いバナー(例: CLASSIFICATION: SENSITIVE, PII, financial, or regulated data …)を付加し、すべての audit レコードにその値がタグ付けされます。ツール名からラベルを再導出することなく、機密レンズのイベントを下流の SIEM におけるより厳格な保持 / ACL パスへ振り分けます。情報提供目的であり、ガードレールは引き続き block / sqlGuard / redact です。

サプライチェーン防御

• 初回使用時の検疫(オプトイン、firstRun: approve)は、ツールポイズニングに対する二層防御です。悪意のある、あるいは侵害された上流 MCP が、新しいツールをこっそり追加したり、ツールを削除したり、ツールの説明を改変したりする事態(既知のプロンプトインジェクションベクター)に対処します。JanuScope は ~/.januscope/approved.json 内で、レンズ ID ごとに 2 つのフィンガープリントを追跡します。

  1. 静的レイヤー: プロキシが何を強制するかに影響するレンズ設定サーフェス(ターゲットコマンド、ブロックリスト、sqlGuard ツール、rateLimit ルール、redact ルールの形状)のフィンガープリントです。ターゲットが起動する前に計算されます。「運用者(または攻撃者)がレンズ YAML を編集した」ことを検知します。
  2. ライブレイヤー: 上流 MCP の実際の tools/list レスポンス(すべてのツールの名前、説明、inputSchema、アノテーション)のフィンガープリントです。すべての tools/list レスポンスで再チェックされ、セッション内の最初の 1 回だけではありません。これにより、侵害された上流が最初のチェックを通過した後に(notifications/tools/list_changed の後で)セッション途中でサーフェスを改変することができません。ドリフトは、レスポンスを JSON-RPC エラーに書き換えて強制されるため、MCP クライアントは明確な拒否を目にします。

  januscope approve --config <path> を実行すると、両方のフィンガープリントがアトミックに記録されます。静的フィンガープリントはレンズ設定から、ライブフィンガープリントはターゲットを起動して標準の initialize + tools/list ハンドシェイクを実行し、その結果をハッシュ化することで記録されます。approve 時にターゲットに到達できない場合でも、静的フィンガープリントは依然として記録され、ライブフィンガープリントは次回の実際の実行時に TOFU されます。ライブキャプチャを完全にスキップするには --no-probe を渡します。以降の起動時にどちらかのレイヤーがドリフトすると、同じ修復手順(januscope approve --config <path> で再ベースライン化)でサーフェスが拒否されます。標準入力セーフで、対話的なプロンプトはなく、運用者は帯域外で再承認します。

可観測性

• OpenTelemetry トレーシング（オプトイン、telemetry.otel）。パイプラインは handleClientMessage / handleServerMessage ごとに 1 つのルートスパン、オーバーレイ呼び出しごとに 1 つの子スパンを出力し、JSON-RPC メソッド、ツール名、オーバーレイの結果（forwarded / short_circuited / dropped / gate_failure）、および設定されている場合は classification の属性を付与します。OTLP HTTP エクスポーター経由で任意のコレクター（Jaeger、Grafana Tempo、Honeycomb など）に送信されます。OTel パッケージはオプションのピア依存関係であり、トレーシングが必要な場合にのみインストールしてください。デフォルトのインストールは軽量なままです。現在の制限: ルートスパンと子スパンは明示的な親子リンクなしで出力され、ホストがすでに OTel コンテキスト伝播を有効化している場合にのみ同じトレース ID を共有します。それ以外の場合は、パイプラインルートをキーとするフラットな兄弟リストになると想定してください。コンテキストのスレッディングは今後の対応です。

内部の仕組み: 実際に機能する詳細

キーワードスキャンによる SQL ガードや「すべてにこの正規表現を適用する」リダクターは、簡単な 80% です。現実世界のバイパスの残り 20% を捕捉する部分こそ、私たちがテストで固定しているものです:

• 先頭動詞の許可リストを超える sqlGuard。 また、WITH x AS (DELETE …) SELECT …（CTE に隠された変更）、SELECT … INTO shadow_table FROM users（SELECT-INTO はテーブルを作成）、EXPLAIN ANALYZE DELETE …（EXPLAIN は ANALYZE のために実行される）、COPY … PROGRAM …（Postgres の COPY PROGRAM を介した RCE）、および 17 名の Postgres 管理関数デナイリスト（pg_sleep、lo_import、lo_export、dblink、…）を拒否します。行ロック句（FOR UPDATE）は、正当な読み取りが過剰にブロックされないよう明示的にホワイトリスト化されています。これらのすべてはテストファイルで固定されています。
• redact は関数リプレーサーを使用します。 String.prototype.replace に文字列の置換を渡すと、$&、$1、$$ などが_一致したシークレット_をスクラブ後の出力に補間してしまい、オーバーレイの目的とは正反対になります。私たちは () => replacement を使用するため、置換は常にリテラルです。test/overlays/redact.test.ts:123 で固定されています。
• ナラティブエンベロープ内の構造化行。 公式 MongoDB MCP は結果を <untrusted-user-data-…>…</untrusted-user-data-…> タグでラップします。リダクターは複数の埋め込み JSON スパンとサポートされている Python 行表現を処理し、周囲の散文、コンテナインデックス、および無関係な型付き値を保持します。重複キーやすでに認識済みの未サポートまたは不正な行コンテナは、フィールドルールがリダクションを要求する場合に拒否されます。これにより、field: "**.email" がメッセージ全体の JSON パースでは見逃す値に到達できます。
• audit はモード 0o600 で開きます。 ほとんどのホストのデフォルト umask では 0o644 になり、誰でも読み取り可能となり、logRawArgs: true の場合、ファイルには生の SQL、リクエストボディ、ファイルの内容が含まれます。私たちは明示的に 0o600 で開き、リグレッションテストで権限を stat 検証します。
• パイプラインはゲートと必須リダクションに対して CLOSED で失敗します。 block、sqlGuard、または別のゲートが例外をスローした場合、未チェックのメッセージはどちらの方向でも保留されます。必須リダクションの例外も、JSON-RPC エラーを含む元のレスポンスを保留します。ID を持つメッセージは、要求側で -32603 を受信し、文字列、数値、または null の ID が保持され、無効な ID は null に置き換えられます。ID のない通知はドロップされます。診断は、機密ペイロードをコピーせずに、失敗したオーバーレイとエラーカテゴリを特定します。オプションのオブザーバーの失敗は引き続き継続できます。両方のパスが固定されています。
• バンドルされたレンズにはライブプローブコマンドがあります。 npm run validate:lenses:probe は各ターゲット MCP を起動し、tools/list を実行して、レンズのブロックリストを実際のツール名と差分比較します。これが Atlassian のキャメルケースのバグと Linear の save_* ファミリーを捕捉したものであり、コントリビューターが PR を開く前に利用できます。敵対的なレビュアーの最初の質問を先回りします: 「あなたのブロックリストは実際に何かをブロックしていますか?」

レンズ: コミュニティエコシステム

レンズとは、特定の MCP サーバー向けにすぐ使える JanuScope ポリシーであり、config.yaml とドキュメントで構成され、その MCP のツールサーフェスとよくある落とし穴をカバーするようにキュレーションされています。レンズは lenses/ にあります。閲覧、使用、または貢献してください。

januscope lenses list                       # show every bundled lens
januscope lenses show mongodb-official      # print its config + README

バンドルされているレンズ (20)

サービスごとに 1 つのレンズがあり、公式ベンダーの MCP が存在する場合はそれを指しています。コミュニティによる代替は、単一のベンダーが存在しない技術 (Postgres、MySQL、SQLite) に限って含まれています。各レンズの README には、そのアップストリームのステータスと、利用可能な場合はテスト済みのバージョンおよび日付が記録されています。これらはスナップショットであり、現在のすべてのアップストリームリリースを保証するものではありません。

📊 データベース

• postgres-crystaldba: Postgres MCP Pro。--access-mode=restricted をハードコードし、Postgres の危険な関数の拒否リストを備えた sqlGuard、マルチスキーマ対応のスキーマ事前注入、PII の秘匿化、監査を追加します。

• mysql-benborla29: @benborla29/mcp-server-mysql。mysql_query は sqlGuard で制御され、MCP レベルの書き込みは ALLOW_*_OPERATION=false によってハードコードで無効化されています。

• mongodb-official: MongoDB 公式 MCP。DB と Atlas への書き込みをロックし、PII の秘匿化は返却される JSON ドキュメントの内部まで及びます。

• clickhouse-official: ClickHouse 公式 MCP。run_query に対する許可リストモードの sqlGuard、PII の秘匿化、監査。

• redis-official: redis/mcp-redis。読み取り専用の Redis(47 個のツール、23 個のミューテーションをブロック)。標準の rediss:// URI を介して、セルフホスト、Redis Cloud、AWS ElastiCache、Upstash に対して動作します。返却される値に対する充実した正規表現カバレッジ(セッショントークン、JWT、bcrypt、クラウドキー)。負荷の高い反復ツールにはレート制限を適用します。

• sqlite-panasenco: panasenco/mcp-sqlite。sqlite_execute に対する sqlGuard に加え、定型クエリ向けの防御的な書き込み動詞の glob を備えています。

• mssql-azure-dab: Azure SQL / SQL Server / SQLDW / Cosmos DB / PostgreSQL / MySQL 向けの Data API builder v1.7+ MCP。書き込み形式のすべての DML ツール(create_record、update_record、delete_record、execute_entity)をブロックし、PII の秘匿化、監査を行います。

• oracle-db-sqlcl: Oracle SQLcl 25.4+ 内蔵 MCP。run-sqlcl(HOST シェルエスケープを含む SQLcl メタコマンド)をブロックし、run-sql に対する sqlGuard でキーワードレベルの書き込みを拒否し、PII の秘匿化、監査を行います。

• supabase-selfhost: mcp-remote を介して http://127.0.0.1:54321/mcp のローカル CLI スタックに対して動作する Supabase セルフホスト MCP。apply_migration をブロックし、execute_sql に対する sqlGuard、JWT 形式のトークンを含む PII の秘匿化、監査を行います。

• neon-cloud: API キー認証とサーバー側の ?readonly=true を用いて mcp-remote 経由で動作する Neon ホスト型 MCP。get_connection_string(DSN 認証情報の漏洩)をブロックし、run_sql と run_sql_transaction に対する sqlGuard、DSN 形式の値を含む PII の秘匿化、監査を行います。

• snowflake-labs: PAT 認証を用いて uvx 経由で動作する Snowflake-Labs/mcp。汎用的な DDL 書き込みツール create_object / drop_object / create_or_alter_object(および防御的な glob)をブロックし、run_snowflake_query に対する sqlGuard、PAT/JWT 形式のトークンを含む PII の秘匿化、監査を行います。この MCP が必須とする --service-config-file 用の services.example.yaml が含まれています。

• aurora-dsql: AWS IAM 認証を用いて uvx 経由で動作する awslabs.aurora-dsql-mcp-server。MCP はデフォルトの読み取り専用モードで動作し(--allow-writes なし)、readonly_query に sqlGuard を重ね、DSN 形式の値を含む PII の秘匿化、監査を行います。

• redshift: AWS IAM 認証を用いて uvx 経由で動作する awslabs.redshift-mcp-server。プロビジョニング済みクラスターと Serverless ワークグループの両方を検出し、execute_query に対する sqlGuard、JDBC Redshift / Postgres の DSN 形式を含む PII の秘匿化、監査を行います。README には最小限の IAM ポリシーが含まれています。 🔧 開発者ツール

• github-official: GitHub 公式の Go MCP。GITHUB_READ_ONLY=1 と厳選された GITHUB_TOOLSETS を指定して Docker で実行されます。多層防御としてプロキシ層での書き込みブロックを実施し、ファイル内容に対して広範なシークレットの秘匿処理を行います。

• filesystem-mcp-official: MCP リファレンスのファイルシステムサーバー。write_file / edit_file / create_directory / move_file をロックします。広範なシークレットの秘匿処理(クラウドキー、PAT、PEM、DB URL、.env、JWT)に対応しています。

💼 SaaS

• stripe-official: Stripe 公式の MCP。返金、支払い、キャンセル、および汎用 REST バイパスである stripe_api_execute をロックします。カード PAN、Stripe キー、メールアドレス、電話番号をスクラブします。
• notion-official: Notion 公式のホスト型 MCP を mcp-remote 経由で利用します。
• atlassian-official: Atlassian 公式の Rovo MCP を mcp-remote 経由で利用します。Jira、Confluence、Compass。
• linear-remote: Linear 公式のリモート MCP を mcp-remote 経由で利用します。
• supabase-cloud: Supabase ホスト型 MCP。mcp.supabase.com に mcp-remote と PAT 認証で接続します。すべてのプロジェクト / ブランチ / マイグレーション / エッジファンクションの書き込みをブロックし(10 個のツール + 防御的 glob)、execute_sql には sqlGuard を適用します。DSN や JWT の形式を含む PII の秘匿処理と監査を実施します。ローカル開発用の MCP については supabase-selfhost を参照してください。

レンズのコントリビュート

新しいレンズが追加されるたびに、このツールの価値は高まっていきます。ここに掲載されていない MCP に対して JanuScope を実行した場合は、ぜひレンズをコントリビュートしてください。所要時間は約 15 分で、その後その MCP を使うすべての人に役立ちます。特に MCP の作者の方には、ご自身のサーバー用のレンズを提出していただけると幸いです。

• レンズを自分で書きたくない場合は、レンズリクエストを作成してください。対象の MCP が対応可能そうであれば、メンテナーまたはコミュニティのコントリビューターが対応します。

ツール名は MCP ごとに異なります。 ポリシーを作成する前に、対象の MCP に対して tools/list を一度実行し、実際に公開されているツールを確認してください。各レンズの README には、そのレンズが前提としているツール名が記載されているので、フォークや代替実装に合わせて調整できます。

ベンチマーク: モデル化ではなく実測

以下の元の 3 つの表は、同じプロンプトを Claude Sonnet 4.5 で raw の Postgres MCP と、同じ MCP を JanuScope Lens でラップしたものに対して実行し、Anthropic API のレスポンスメタデータからトークン使用量を取得した過去の結果です。すべての数値は 4 回の独立した実行の中央値です(Sonnet は非決定的であり、1 回の実行の数値を看板として提示するのは妥当ではありません)。これらの結果は元のハーネスとポリシーを使用したものであり、改訂された同梱の文言を測定したものではありません。

パフォーマンス (典型的な分析クエスチョン)

プロンプト:「所有するサイトとページ全体で、監査件数の合計が多い上位5ユーザーを見つけてください。」

同じモデル、同じデータベース、毎回同じ正解です。ベースラインは一貫してスキーマの把握に5ターン / 7ツール呼び出しを費やしました (テーブルの一覧表示、テーブルの説明、クエリの調整)。一方、JanuScope の実行は一貫して2ターン / 1ツール呼び出しでした。これは、最初の呼び出しからスキーマが query ツールの説明に組み込まれていたためです。ツール呼び出し数とターン数は実行間でまったく安定しており、トークン数は±5%変動します。

複数質問セッション (償却後の見方)

元のハーネスはクライアントセッションを再利用しましたが、質問間で会話履歴をリセットしていました。したがって、増え続ける保持された会話をテストしておらず、単一質問の結果は節約量の保証された下限ではありません。プロンプトキャッシュは有効化されており、表は元の3質問の合計を、4回の実行の中央値とともに示しています:

• ベースラインの範囲は広範囲です (最小 93k トークン、最大 146k)。1回の実行で Q3 の1つが 118k トークンまで増加しました。これはそのハーネスにおける探索を記録したものであり、一般的な最悪ケースの推定値ではありません。
• JanuScope の合計は安定しています (20k ±1k)。この観察は、将来のモデルの作業量の限界を立証するものではありません。

安全性（3 つの敵対的プロンプト）

フォローアップのベンチマークでは、3 つの敵対的プロンプトを同じ 2 つのパイプラインに通し、ユーザーが実際に読む最終回答に何が漏れ出すかを数えます。方法論は上記と同じ 4 回実行の中央値です。合格率は、JanuScope が 3 つすべて のプロンプトで一線を守った実行回数です。

決定的なのは真ん中の行です。Claude 自身の安全トレーニングは 明白な リクエストは確実に拒否しますが、微妙な枠組みについては一貫性がなく、ベースラインは 4 回の独立した実行のうち 2 回 で漏洩しました（サンプルが小さいため、これはベースラインがここでは 信頼できない という証拠として扱うべきであり、正確な漏洩率としてではありません）。そして 2 回の「クリーンな」実行はベースラインの特性ではなく、Sonnet の非決定性の特性です。過去の JanuScope の回答は、3 つすべてのプロンプトにわたる 4 回の実行すべてで拒否しました。 これらの観察は、どのオーバーレイが拒否を引き起こしたかを特定するものではなく、すべての SQL の変更や保護された値の変換がブロックされることを証明するものでもありません。より新しい敵対的テストで失敗が見つかっており、以下に記載します。

これらの数値が積み上がる理由

スキーマコンテキストは発見を減らせますが、これらの測定は、節約がすべてのセッションで積み上がることを証明するものではありません:

1. マルチターンセッション。 保持された履歴は、どちらの経路でも発見を再利用できます。キャッシュはそのコストを変えます。以下の新しいマッチ履歴テストはこれを直接測定しています。
2. より大きなスキーマ。 発見作業と注入されるコンテキストの両方が増大しえます。元のテストは、100 テーブルのスキーマにおける節約を証明していません。
3. 異なるモデル。 元の Sonnet の結果は、Opus や Haiku の優位性を証明するものではありません。結果はモデル、文言、タスク、クライアントの挙動に依存します。

元の生のスクリプトと実行は公開されていません。評価レポートには、新しい方法論、結果、限界が記録されています。

新しい評価と改訂された Lens の指示。 instructions は、ツールの説明に追加されるオプションのポリシー文章です。バンドルされた Lens にはこれが含まれますが、カスタムポリシーでは省略できます。改訂された文言は、機密フィールド、バイパス、バックエンドに関する明示的なルールを保持しています。PostgreSQL のポリシーは 255 語から 193 語に変わり、20 個の Lens 全体のコレクションは 3,115 語から 3,745 語に変わります。これは、短くなったポリシーが欠けていた保護機構を獲得したためです。指示以外の設定と指示の配置は維持されています。

• 初期の単純化: 作成された指示を削除すると、合成の 5 テーブルテストにおいて、ネイティブと比べてトークンの 57.1%、**推定コストの 56.7%**を節約し、各アームで 12/12 の正解でした。この削除はテスト変種であり、改訂されたバンドルポリシーではありません。ネイティブ MCP に同じコンテキストを与えても、同様の発見の節約が達成されました。
• より広範な変種: 225 回答のプロトタイプ比較では、各アームで 39/39 の正しい分析回答が得られ、その短いポリシーではスタンドアロンタスクにおいてトークンが 46.0% 少なく、推定コストが 43.9% 少ないという結果でした。それでもマスクされた値とサフィックスのリクエストには失敗しました。別の 182 回答の中間比較では、両方のポリシーでスタンドアロン回答が 21/21 正解でしたが、すべての分析タスクでは改訂版が 42/43 に対し元版が 43/43でした。これらは初期の変種であり、最終的な文言ではありません。
• 20 個の Lens 全体: 2 回目の完全なモデルガイダンス比較では、改訂された文言が、保護された読み取りを含む安全性の回答を41/60 から 1/60に、書き込みを4/60 から 2/60に減らしました。通常の値は、両方の文言で20/20のタスクで正解でした。これらはプロキシによる強制を伴わない合成アダプターを使用しており、認証されたベンダーの挙動を証明するものではなく、バイパスを排除するものでもありません。
• 最終的な的を絞った 27 タスク: 元の PostgreSQL の文言は9/9正解し、改訂された文言は8/9正解し、重複名のグループ化ケースを 1 つ失敗しました。どちらも、保持された会話と許可された要約のすべてのチェックに合格しました。マッチした保持会話は、改訂された文言でトークンが 9.3〜9.6% 少なく、推定コストが 8.1〜8.8% 少ないという結果でした。他の 9 つの Lens タスクは9/9 の正しい値を返しましたが、厳密なプレーン JSON 要件を満たしたのは0/9でした。許可された抜粋に関するその後の 6 語のファイルシステムの明確化は、モデルでテストされていません。
• 強制された機密データアクセス: バックエンドの権限を制限した別のローカル PostgreSQL テストでは、30/30の正当なチェックを許可し、87/87の保護されたアクセスの試行を拒否しました。応答フィルタリングだけでは、任意のエイリアス、エンコーディング、派生値を防ぐことはできません。バックエンド権限ガイドを参照してください。

これらの結果は、測定されたケースにおいて、有用なガイダンスと削減されたコンテキストを裏付けていますが、既知の失敗もあります。すべてのワークフローで同等の有効性、普遍的な節約、普遍的なプライバシーを証明するものではありません。評価の詳細全体。

設定リファレンス

target を除くすべてのトップレベルフィールドは任意です。最小構成の設定は 3 行です。

target: # required
  command: <string> # executable (e.g. "npx", "node", or an absolute path)
  args: [<string>] # optional
  env: { <name>: <value> } # optional; merged with inherited process env
  cwd: <string> # optional

classification:
  public|internal|sensitive # optional lens data-sensitivity label.
  # When set, `instructions` adds a short banner to
  # every tool description and `audit` tags every record
  # with `classification: "<value>"`. Purely informational;
  # enforcement still lives in `block` / `sqlGuard` / `redact`.

firstRun:
  approve # optional; when set, the runtime fingerprints the lens
  # via TWO independent layers, both stored in
  # ~/.januscope/approved.json:
  #   (1) Static lens fingerprint: block rules + sqlGuard
  #       tools + rateLimit rules + redact rule shapes +
  #       target command. Refuses startup on drift.
  #   (2) Live tools/list fingerprint: every upstream tool's
  #       name + description + inputSchema + annotations.
  #       Re-checked on EVERY tools/list response (not just
  #       the first), so a compromised upstream cannot pass
  #       the initial check and then mutate the surface mid-
  #       session via notifications/tools/list_changed.
  #       Rewrites tools/list into a JSON-RPC error on drift.
  # Run `januscope approve --config <path>` to re-baseline
  # both layers atomically (probes the target, captures the
  # live tools, persists both fingerprints). Pass --no-probe
  # to skip the live capture and let it TOFU on next run.
  # Defends against tool-poisoning where a malicious MCP
  # quietly adds a tool, mutates a description (prompt-
  # injection vector), or changes a tool's input schema.

block: # array of tool names or globs; "admin_*" supported
  - <name or glob>

instructions: <string> # appended to every tool description

dbSchema:
  driver: postgres|mysql|sqlite # optional; inferred from connectionString prefix
  connectionString: <string>
  tables: [<string>] # allowlist (mutually exclusive with excludeTables)
  excludeTables: [<string>]
  schemas:
    [<string>] # Postgres only. Defaults to ["public"]. Set for
    # multi-schema deployments (e.g. ["app", "analytics"]).
    # MySQL and SQLite drivers ignore this.
  injectInto: [<string>] # which tool names receive the schema; defaults to common SQL names
  format: markdown|ddl|compact
  includeComments: <bool> # false omits table, view and column comments in Postgres/MySQL metadata
  refresh: startup|never

contextInjection: # static counterpart to dbSchema; same goal, operator-supplied text
  injectInto: [<tool-name>] # tools whose `description` receives the text; required, ≥1
  text: | # OPTION A: inline string. Mutually exclusive with `textFile`.
    Active projects: PROJ-A, PROJ-B, PROJ-C.
    Issue states: backlog, todo, in_progress, in_review, done, cancelled.
  # textFile: ./context.md  # OPTION B: path. Mutually exclusive with `text`.
  # Relative paths resolve against this lens's config.yaml directory.
  # `~/...` expands to the home dir. Absolute paths are used as-is.
  position: append|prepend # default "append" (after the upstream description)

redact:
  rules:
    - regex:
        <pattern> # scans every text content block. Leading PCRE-style
        # inline flags are supported: `(?i)password` →
        # case-insensitive, `(?is)` → +dotall, etc.
    - field:
        <path> # dotted path with * (one level), ** (any depth), [i] (index).
        # Auto-parses JSON strings inside text blocks, and
        # also processes balanced JSON and Python row spans
        # embedded in a narrative envelope (e.g. MongoDB's
        # <untrusted-user-data-…> wrapper).
  replacement: <string> # default "[REDACTED]"
  applyTo: text|all|fields

sqlGuard:
  tools: [<tool-name>] # which tool(s) carry a SQL argument
  sqlArg: <name> # default "sql"
  readOnly: <bool> # default true; rejects mutations in the SQL argument
  mode:
    allowlist|denylist # default "allowlist" (recommended)
    # allowlist: accept only leading read verbs
    #   (SELECT / WITH / SHOW / EXPLAIN / DESCRIBE /
    #   VALUES / PRAGMA / TABLE) AND reject any
    #   embedded DML / DDL keyword or SELECT INTO
    #   hiding inside a WITH CTE / EXPLAIN ANALYZE.
    # denylist: legacy keyword-blacklist; preserved
    #   for compatibility.
  extraReadVerbs:
    [<word>, ...] # allowlist mode: dialect-specific
    # read verbs your MCP needs on top of the defaults.
  extraWriteKeywords: [<word>, ...] # denylist mode only (ignored otherwise).

rateLimit: # array of rules; first matching rule wins
  - tool: <name or glob> # exact tool name or "*"-glob (same as `block`)
    perMinute: <number> # steady-state rate; bucket starts full at <perMinute>.
    # Each matched *tool* gets its own bucket, so one hot
    # tool can't starve others that share the same rule.
    # `per_minute` (snake_case) is also accepted.

telemetry: # optional; omit entirely for zero-overhead (no-op tracer)
  otel:
    endpoint: <url> # OTLP HTTP endpoint
    # e.g. "http://otel-collector:4318/v1/traces"
    serviceName: <string> # optional; default "januscope"
    headers: # optional auth / routing headers
      Authorization: "Bearer ${OTEL_TOKEN}"
  # Install the peer deps only when you enable this:
  #   npm install @opentelemetry/api @opentelemetry/sdk-trace-base \
  #               @opentelemetry/exporter-trace-otlp-http \
  #               @opentelemetry/resources

audit:
  sink:
    <path|stderr|stdout> # "~" is expanded. Parent directories
    # are auto-created. File opens with 0o600
    # perms (user-only; matters for logRawArgs).
  logRawArgs: <bool> # default false; when false, args are SHA-256 hashed

文字列値内の環境変数は ${VAR} または $VAR で展開されます。存在しない変数は空文字列になり、stderr に 1 行の [januscope] warn: env var 'FOO' is unset, substituted empty string を出力します（名前ごとに 1 回）。起動を拒否することはありません。ユーザーが未定義の変数で意図的にテストしている可能性があるためです。ただし、警告は十分に目立つため、午前 2 時に $DATABASE_URL を忘れた場合、レンズがサイレントに壊れる代わりにログに現れます。

クレデンシャルボルト参照（任意）

単純な ${VAR} 置換に加えて、起動時に外部シークレットストアから 3 種類の URI 形式の参照が解決されます。

#<field> は保存されたオブジェクトから 1 つのフィールドを選択します。シークレットにフィールドが 1 つだけの場合は省略できます。同期の loadConfig() はボルト参照を含む設定を拒否し、非同期の loadConfigAsync() を案内します。CLI は常に非同期パスを使用するため、januscope --config … は両方のケースを透過的に処理します。

設計上の注意: リゾルバーは起動時にのみフェッチします。JanuScope は値を一度読み取り、置換済みの設定をパイプラインに渡し、プロセスの存続期間中にシークレットストアを再度呼び出すことはありません。シークレットをローテーションしてください。JanuScope を再起動してください。

仕組み

MCP サーバーは、stdio 上で JSON-RPC 2.0 を話すプログラムです。JanuScope もまた、stdio 上で JSON-RPC 2.0 を話すプログラムですが、実際の MCP サーバーを子プロセスとして起動し、オーバーレイのパイプラインを通じてメッセージを転送する点が異なります。

[AI client] ──stdin/stdout──> [januscope] ──stdin/stdout──> [real MCP server]
                                   ▲
                            rewrites tools/list
                            short-circuits blocked tools/call
                            injects schema, scrubs output, logs

デーモンや待ち受けポートはありません。永続状態は、設定された監査ログと任意の初回使用承認に限定されます。上流のブリッジは独自の認証状態を維持できます。JanuScope はクライアントの接続と同じだけ存続し、それとともに終了します。全体像については ARCHITECTURE.md を参照してください。

dbSchema と contextInjection の実際の動作

これらは LLM が見るツール説明にコンテキストを追加する 2 つのオーバーレイです。仕組みは同じで、異なるのはテキストの出所です。

ウォークスルー、Postgres に対する dbSchema

1. レンズの読み込み。 JanuScope は config.yaml を読み込みます。dbSchema: ブロックはレシピです（ドライバー、接続文字列、参照するスキーマ、注入するツール）。スキーマのテキスト自体は YAML には 含まれません。
2. 起動時のイントロスペクション。 JanuScope はレシピの connectionString を使って実際の Postgres 接続を開き、いくつかの information_schema クエリを実行します。テーブル名、カラム、型、外部キー、そして（includeComments: true の場合）SQL コメントを取得します。これには 50～300 ms かかり、起動ごとに 1 回だけ 実行されます。
3. シリアライズ。 イントロスペクションの結果は、読みやすいテキストの塊（デフォルトでは Markdown）に整形されます。JanuScope はこの塊をディスクに書き込まずにメモリ上に保持し、ツールの説明の中で MCP クライアントに送信します。クライアントとそのモデルプロバイダーはこれを受け取ることができます。
4. MCP ハンドシェイク。 MCP クライアント（Claude / Cursor など）が tools/list を JanuScope に送信します。JanuScope はそれを実際の Postgres MCP に転送します。MCP は標準の説明とともにツールリストを返します。
5. 注入。 レスポンスをクライアントに返す前に、dbSchema オーバーレイがそれを書き換えます。injectInto: にある各ツール名（通常は execute_sql）について、スキーマの塊がそのツールの description フィールドに追加されます。
6. LLM は強化されたツールを見る。 Claude / Cursor は説明を読み、最初のクエリを書く前に、どのテーブルが存在し、どのようなカラムがあるのかを把握します。list_tables の往復は不要です。

スキーマコンテキストは、測定されたディスカバリー削減の大部分を説明します。当初の 84% という結果は会話履歴を対象としたものでした。上記の新しい会話保持の比較を参照してください。

ウォークスルー、Linear に対する contextInjection

contextInjection は同じ考え方ですが、イントロスペクターはオペレーターです。JanuScope は Linear（や Notion、ファイルシステム）を「イントロスペクト」する方法を知らないため、オペレーターがテキストを用意します。ストレージの選択肢は 2 つあります。

• インライン（text: |）。 短く、手作業で厳選された、あまり変わらないコンテキストに最適です。テキストはレンズの config.yaml に直接記述します。

  contextInjection:
    injectInto: [list_issues, search_issues, get_issue]
    text: |
      Active projects: PROJ-A (engineering), PROJ-B (data), PROJ-C (growth).
      Issue states: backlog, todo, in_progress, in_review, done, cancelled.
  

• 外部ファイル（textFile: ./context.md）。 コンテキストが長い場合や、外部のジョブ（cron、CI、自作スクリプト）がそれを最新の状態に保つ場合に最適です。レンズの config.yaml がパスでファイルを参照します。

  contextInjection:
    injectInto: [list_issues, search_issues, get_issue]
    textFile: ./linear-context.md # next to config.yaml
  

  相対パスはレンズのディレクトリを基準に解決されるため、config.yaml の隣に context.md を同梱して出荷されるレンズは、オペレーターがどこから JanuScope を起動しても動作します。絶対パスと ~/... パスも使用できます。

オペレーターは、linear-context.md を 1 時間ごと（またはコミット時、あるいは任意のタイミング）に再生成する別の cron ジョブを実行できます。JanuScope は、プロキシが次に起動したときに新しいコンテンツを取得します。JanuScope 自体は Linear からフェッチしません。この分離は意図的なもので、コアに API 統合を組み込むことなく、同じオーバーレイがどのレンズでも機能するようにしています。

ランタイムの経路は上記のステップ 4～6 と同一です。次回の tools/list レスポンスで、JanuScope は injectInto にリストされたすべてのツールの説明にテキストを追加（または position: prepend の場合は先頭に追加）します。

どちらを使うべきか

• 対象が Postgres / MySQL / SQLite であるレンズには dbSchema を使用します。JanuScope がイントロスペクションを処理します。
• 非 DB のレンズで、LLM が otherwise 発見しなければならない小さく安定した表面がある場合は contextInjection を使用します。適した例: Linear（プロジェクト / チーム / ステータス列挙型）、Atlassian（プロジェクト / スペース）、ファイルシステム（厳密に許可されたルートのディレクトリスケルトン）、Notion（ワークスペースナビゲーションのスケルトン）。限界的な例: Stripe（ほとんどが ID 直接指定の使用）、GitHub（ほとんどが ID 直接指定の使用）。不適な例: 大きなもの（ファイル内容全体、アクティビティフィード全体）や変動の激しいもの（リアルタイムのイシュー数、最近のメッセージ）。
• 両方を同じレンズで実行できます。これらは独立しています。DB に支えられた SaaS に対するレンズでは、SQL ツールに dbSchema を使い、別の非 SQL ツールに列挙値の用語集を追加するために contextInjection を使うことができます。

クラッシュ、再起動、ヘルスチェック

JanuScope は MCP クライアントの子プロセスとして起動される stdio プロキシであるため、そのライフサイクルはクライアントのライフサイクルそのものであり、デーモンも /health エンドポイントも存在しません。これは意図的な設計です。待ち受けポートを持たず、監査ファイルと任意の承認状態はローカルに保持されます。また、これは通常のプロセススーパーバイザーのパターンがそのまま当てはまらないことも意味します。以下に、故障モードの形と、その際に取るべき対応を示します。

• 捕捉されない例外、または致命的な未処理の rejection。 JanuScope は Node の uncaughtExceptionMonitor イベントを監視し、ランタイム診断を書き込みます。Node の通常の致命的動作を抑制するハンドラーはインストールしません。Node のデフォルトのエラーポリシーでは、プロセスは非ゼロで終了し、MCP 接続は閉じられます。デフォルトの診断は終了前に同期的に書き込まれます:

  [januscope:runtime] 2026-01-01T… error: unhandledRejection {"message":"…","stack":"…"}
  

  埋め込みアプリケーションのハンドラー、キャプチャコールバック、および Node の rejection フラグは、それぞれ独自の動作を維持します。したがって、処理済みのエラーがそのアプリケーションの MCP セッションを自動的に切断することはありません。JanuScope はセッションが終了すると、自身のモニターを削除します。Node が exit イベントを発行すると、各アクティブなブリッジは自身が所有する直接ターゲットに SIGKILL を送信します。OS による強制終了、--abort-on-uncaught-exception のようなアボートモード、およびホストの致命的エラーハンドラー内でスローされた失敗は、これらのクリーンアップフックをスキップする可能性があります。これは、独立してデーモン化された子孫のクリーンアップや、最終的な非同期の監査/テレメトリのフラッシュを保証するものではありません。ランタイム診断には元のエラーメッセージとスタックが含まれる可能性があるため、機密情報として扱うべきです。

• ラップされた MCP がクラッシュする、または接続が停止される。 グレースフルシャットダウンは、まずオーバーレイの停止フックを待機します。これらのフックが完了した後、トランスポートはターゲットの stdin を閉じ、2 秒後に SIGTERM、5 秒後に SIGKILL、10 秒の待機期限をスケジュールします。ハングした停止フックはこのシーケンスを遅延させる可能性があります。これらはリクエストごとのタイムアウトでも、一般的なハング検出器でもありません。再接続は MCP クライアントに依存します。新しいプロセスペアを起動するには、クライアントからサーバーを再接続または再起動してください。

• ストリームエラー。 クライアントの stdin またはターゲットの stdout からのエラーは warn としてログに記録されます。これらのハンドラー自体はブリッジを停止しません。EOF、ストリームの終了、およびターゲットの終了は、上記のシャットダウンを開始します。閉じられたクライアント出力またはターゲット入力への書き込みは、非同期の EPIPE エラーを発生させる可能性があります。Node のデフォルトのエラーポリシーでは、これらの未処理エラーは上記の致命的診断と非ゼロ終了の経路に従います。ストリームエラー単独では、グレースフルな終了や done の解決は保証されません。

• スーパーバイザーでの JanuScope の実行。 JanuScope を長時間実行されるサイドカー (例: LLM セッションごとに 1 つの stdio ブリッジを保持するカスタムゲートウェイ) に埋め込む場合は、他の Node プロセスと同様に監視してください: Restart=on-failure を指定した systemd、または Docker の restart: unless-stopped です。上記の stderr 行は、スーパーバイザーがクラッシュとクリーンな終了を区別するのに十分な情報を提供します。

• /health は意図的にありません。 stdio 専用のプロキシに HTTP ヘルスエンドポイントを追加すると、「待ち受けポートを開かない」という方針が損なわれます。生存性の確認には、初期化済みの MCP 接続で tools/list を使用するか、クライアントの接続状態に依存してください。任意の npx -y januscope check --config <name-or-path> 診断は、別のテスト接続のために初期化とディスカバリを実行します。

リモートプリセットは現在、別個の stdio-to-HTTP ブリッジを使用しています。ネイティブの HTTP トランスポートはプロキシに実装されていません。

ログと監査

レンズが audit: を有効にすると、JanuScope は追跡対象の呼び出し結果に加えて起動とシャットダウンのイベントを、1 行につき 1 つの JSON オブジェクトとして、構造化 JSONL ログに書き込みます。書き込みエラーはログに記録され、転送を停止しません。そのため、ログの完全性が重要な場合は、シンクとランタイム診断を監視してください。

シンク

audit:
  sink: ~/mcp-audit-postgres.jsonl # file path, or "stdout" / "stderr"
  logRawArgs: false # default; true = include un-hashed arguments

• ~ はホームディレクトリに展開されます。
• 親ディレクトリが存在しない場合は自動的に作成されます。
• 新しいシンクファイルはモード 0o600（ユーザーの読み取り/書き込みのみ）で開かれます。既存のファイルは現在のモードを保持します。後から logRawArgs: true に切り替える場合は、より厳格なパーミッションを適用するために新しいシンクへローテーションしてください。
• stderr は監査行を診断ストリームに送信します。stdout はオーバーレイでサポートされていますが、CLI では MCP プロトコルのパイプを共有します。MCP クライアント接続にはファイルまたは stderr を使用してください。

イベントスキーマ

すべてのレコードには以下の基本フィールドがあります。

さらにイベント固有のフィールドがあります。

startup は、パイプラインの初期化時に一度だけ書き込まれます。

{ "ts": "2026-04-18T12:00:00.000Z", "event": "startup", "sink": "~/mcp-audit.jsonl" }

tools/call は、追跡対象のレスポンスが到着したときに一度だけ書き込まれ、リクエストのメタデータと結果が同じレコードに含まれます。レスポンスが存在しない場合は、代わりに timeout または orphaned として記録されることがあります。

{
  "ts": "2026-04-18T12:00:01.456Z",
  "event": "tools/call",
  "tool": "query",
  "id": 42,
  "args_hash": "sha256:0123456789abcdef",
  "status": "ok",
  "duration_ms": 333,
  "result_bytes": 2048
}

このレコードは例示用です。ID、ハッシュ、タイミング、バイト数は実際の呼び出しによって異なります。

フィールド:

ID の帰属

JanuScope は起動時に 3 つのオプションの環境変数を読み取り、すべての監査レコードにそれらを付与します。

各フィールドは、対応する環境変数が未設定または空の場合、レコードから省略されるため、単一運用者のワークステーションの場合、JSONL は最小限に保たれます。ライブラリに組み込む開発者は、createAuditOverlay() に直接 identity: { user, team, session } を渡すことで、環境変数の取得を上書きできます。

これは JanuScope の軽量な ID オプションです。SSO、OIDC、RBAC、呼び出しごとの認可は行いません。ホストプロセスがラベルを帯域外で提供し、監査ログがそれらを SIEM まで引き継ぎます。ID ブローカーを立ち上げることなく、「誰がこのクエリを実行したか?」「どの CI ジョブか?」「どの Claude Code セッションか?」に答えるために使用します。

shutdown は、パイプラインが正常に終了したときに書き込まれます:

{ "ts": "2026-04-18T12:15:00.000Z", "event": "shutdown" }

機械可読スキーマ

完全なイベントユニオンは 2 つの形式で提供され、どちらもパッケージに同梱されているため、SIEM の取り込みツールはこの README から形状を書き写す必要がありません:

• TypeScript: パッケージのエントリポイントから AuditEvent ユニオン (およびイベントごとの型) をインポートします:

  import type {
    AuditEvent,
    AuditToolsCallOkEvent,
    AuditToolsCallErrorEvent,
    AuditStartupEvent,
    AuditShutdownEvent,
  } from "januscope";
  

• JSON Schema (Draft 2020-12): Ajv CLI と ajv-formats を使用して各 JSONL レコードを検証します。両方を npm install -g ajv-cli ajv-formats でインストールし、次を実行します:

  (
    set -eu
    audit_schema_path="${audit_schema_path:-node_modules/januscope/schemas/audit-event.json}"
    audit_record_dir=$(mktemp -d "${TMPDIR:-/tmp}/januscope-audit.XXXXXX")
    trap 'rm -rf "$audit_record_dir"' EXIT
    while IFS= read -r line || [ -n "$line" ]; do
      printf '%s\n' "$line" > "$audit_record_dir/record.json"
      ajv --spec=draft2020 -c ajv-formats validate \
        -s "$audit_schema_path" -d "$audit_record_dir/record.json"
    done < my-audit.jsonl
  )
  

  デフォルトのスキーマパスは、ローカルプロジェクトへのインストールを想定しています。グローバルインストールやその他のレイアウトの場合は、このブロックを実行する前に audit_schema_path をそのインストール内のスキーマに設定してください。ソースチェックアウトからは、audit_schema_path=schemas/audit-event.json を使用します。ループは最初の無効なレコードで停止し、改行のない無効な最終行も含まれ、終了時に一時ファイルを削除します。

イベント型は src/overlays/audit.ts で定義されており、同梱の JSON Schema は対応するレコードを記述しています。

ハッシュ化された引数がデフォルトである理由

デフォルトでは args_hash が出力され、args は出力されません。これにより、デフォルトで生のリクエスト引数を保存することなく、同一の繰り返し呼び出し (リプレイ、リトライループ) を検出し、セッションをまたいでリクエストを相関付けることができます。上流の JSON-RPC エラーメッセージや明示的な ID ラベルには、依然として機密データが含まれる可能性があります。logRawArgs: true は、監査ファイルがすでに機密として扱われている環境 (専用のログホスト、暗号化ボリューム、SIEM パイプライン) でのみ有効にしてください。

ログの読み取り

シンプルな tail:

tail -f ~/mcp-audit-postgres.jsonl | jq

直近 100 イベントで MCP レイヤーで失敗したすべての tools/call:

tail -n 100 ~/mcp-audit-postgres.jsonl | jq 'select(.status == "tool_error" or .status == "error")'

モデルが呼び出そうとしたすべての一意なツールを、頻度順に並べたもの:

jq -r 'select(.event == "tools/call") | .tool' ~/mcp-audit-postgres.jsonl \
  | sort | uniq -c | sort -rn

特定の呼び出しの結果を確認する:

jq -c 'select(.event == "tools/call" and .id == 42)' ~/mcp-audit-postgres.jsonl

順序の保証

CLI は audit をレスポンスリダクターより前に登録します。したがって、監査はクライアント向けに一致する値が削除される前に、上流のエラーメッセージを記録できます。生のリクエスト引数は logRawArgs: true の場合にのみログに記録され、成功したレスポンスボディは保存されず、そのバイト数のみが保存されます。YAML のキー順は CLI のオーバーレイ登録順を変更しません。ログは機密として扱い、それに応じて保持とアクセスを設定してください。

# Example configuration (CLI registration order is fixed)
audit: # may record raw args and upstream error messages
  sink: ~/audit.jsonl
  logRawArgs: true
block: # blocks dangerous tools
  - drop_table
sqlGuard: # blocks dangerous SQL
  tools: [query]
instructions: |
  STRICT POLICY. …
redact: # transforms matching response values for the client
  rules:
    - field: "**.email"

保持とローテーション

JanuScope はログ自体をローテーションしません。sink: をパスに向ける場合は、標準の create 0600 <user> ディレクティブを指定して logrotate (Linux) または newsyslog ルール (macOS) を使用し、ローテーションされたファイルが正しいモードを継承するようにします。あるいは、診断ストリームを収集し、ログアグリゲーターに保持を任せてください。監査出力は MCP の stdout パイプから外しておいてください。

ライブラリ API

テストやカスタムゲートウェイへの組み込みには:

import { runOverlay, loadConfig } from "januscope";

const config = loadConfig("./policy.yaml");
await runOverlay({ config });

runOverlay の promise はブリッジのシャットダウンが完了した後に解決されますが、致命的なプロセスエラーが先にプロセスを終了させる可能性があります。公開サーフェスの全体については src/index.ts を参照してください。

JanuScope と Claude Skills

Claude Skills(Anthropic の新しいファーストパーティパターン)と JanuScope は、関連はしていますが異なる問題を解決します。両者は競合するものではなく、組み合わせて使うものです。

Skills は意図を形成します。JanuScope は制限を強制します。本格的なデプロイには両方が必要であり、それが 信頼 + 検証 アーキテクチャです。

FAQ

LLM がターミナルから redis-cli / psql / gh を実行して JanuScope をバイパスしようとしたらどうなりますか? JanuScope が直接止められるものは何もありません。ターミナルはエージェントホスト(Copilot、Cursor、Claude Code)内の兄弟ツールサーフェスであり、ラップされた MCP ではないからです。プロキシは、自身が起動した MCP への JSON-RPC トラフィックしか見えません。これは設計上の仕様であり、SECURITY.md の three-layer model の下に文書化されています:

1. 隠す: block は tools/list から書き込みツールを削除するため、モデルはそれらを目にすることがありません。ブロックされた名前への直接呼び出しも、モデルがそれを推測したとしても拒否されます。JanuScope はこれを提供します。
2. 助言する: instructions(position: prepend 付き)と contextInjection は、モデルが読む説明文に SURFACE BOUNDARY の段落を挿入し、ターミナル / ベンダー CLI / 兄弟 MCP によるバイパスを明示的に禁止します。JanuScope はこれを提供します。これは助言であり、強制ではありません。VS Code Copilot に対して実際に観察されたところでは、モデルはポリシーのテキストを受け取り、尋ねられればそれを暗唱できますが、一部のプロンプトでは自発的にターミナルバイパスを提案することがあります。
3. データパスで強制する: 物理的に変更不可能な認証情報を、JanuScope の上流に設定します(読み取り専用の DB ロール、読み取り専用の Upstash トークン、きめ細かい読み取り専用 PAT、Stripe の rk_*)。JanuScope はこのレイヤーを提供できません。 レイヤー1と2が機能しない場合の、実際の障壁となるものです。

デモ / 非本番用途では、通常はレイヤー1と2だけで十分です。データは使い捨てであり、エージェントは監督下にあるからです。本番デプロイでは、レイヤー3が必須です。 同梱の各レンズの README には、そのバックエンドに推奨されるレイヤー3の認証情報を文書化した Prerequisites セクションがあります。これは提案ではなく、デプロイ要件として扱ってください。

これはリモート MCP サーバーで動作しますか? はい、現在は linear-remote、notion-official、atlassian-official などの同梱レンズを通じて動作します。それぞれがベンダーの Streamable HTTP エンドポイントの前段に stdio↔HTTPS ブリッジとして mcp-remote を起動し(OAuth フローも処理します)、JanuScope はそのブリッジを他の stdio MCP と同様にラップします。JanuScope 内部でのネイティブな Streamable HTTP トランスポート(mcp-remote のホップなし)は実装されていません。インストールと認証の詳細については、以下の「mcp-remote とは...」を参照してください。

パフォーマンスのオーバーヘッドはどれくらいですか? プロセス内の呼び出しごとのオーバーヘッドはサブミリ秒です。Node 22 / M2 上で npm run bench:overhead(完全な Pipeline に対する 10,000 回反復のマイクロベンチマーク、監査シンクは一時ファイルを指定)で測定した数値は、おおよそ次のとおりです:

つまり、最も負荷の高い構成であっても、パイプライン自体のコストはリクエストあたり数十マイクロ秒であり、一般的な LLM のラウンドトリップより4～5桁低く、MCP 子プロセスの IO から見ればノイズにすぎません。dbSchema がサイクルごとの表から除外されているのは、そのリクエストごとの処理が tools/list の書き換え（セッションごとに1回実行）だけだからです。その_セットアップ_コストは、起動時の実際の DB イントロスペクションで約50～300 ms です。お使いのハードウェアで機械可読なスナップショットを取得するには、npm run bench:overhead -- --json を実行してください。

redact.rules: regex と field はいつ使うべきですか？ 本格的なレンズでは両方を使います。field ルールは列名やプロパティ名（**.email、**.password、users[*].stripe_id）を対象とし、テキストコンテンツブロック内の対応する JSON および Python 形式の行を処理するため、SQL MCP の出力にある一致するフィールドにも到達できます。エイリアスや変換された値はこれらのルールをすり抜ける可能性があります。regex ルールは、列名に紐づかない値のパターン、フリーフォームテキスト内のメールアドレス、bcrypt ハッシュのプレフィックス、Stripe/AWS のキー形式を捕捉します。この2つは補完的です。field ルールはより精密で、regex ルールはより寛容です。

block と sqlGuard は、それぞれいつ適用されますか？ block はツール名の粒度でフィルタリングします。対象の MCP が書き込み可能なツールを個別のツール（例: write_query、create_table、drop_table）として公開している場合に使用します。ツール全体をブロックします。sqlGuard はさらに一段深く動作します。MCP が query や execute_sql のような任意の SQL を受け付ける単一のツールを持っている場合、block ではそのツールを通じて SELECT と UPDATE を区別できませんが、sqlGuard は SQL 引数を検査し、書き込みキーワードを含むものを拒否します。本格的なレンズでは多くの場合、両方を使用します。明らかに名前から書き込み用とわかるツールには block を、汎用 SQL ツールには sqlGuard を適用します。

sqlGuard は本物の SQL パーサーですか？ いいえ、コメント除去と文字列リテラルの空白化を行った後のキーワードマッチングです。これで、LLM が生成した安易な書き込みを阻止するには十分であり、これが想定する脅威モデルです。意図的な攻撃者はこれを回避するクエリを作成できます。高保証が必要な用途では、MCP に RDBMS レベルで物理的に読み取り専用のデータベースユーザーを与えることもしてください。多層防御です。

sqlGuard が特に捕捉しないものは何ですか？ 文書化された3つのクラスがあります。

1. 名前に DML 動詞の断片で始まるユーザー定義関数、例: SELECT schema.delete_all() や SELECT purge_audits()。JavaScript の \b は _ を単語文字として扱うため、\bDELETE\b は delete_all の内部に一致しません。SELECT dropUsers() も同じクラスです。これらを追跡するには、本物の SQL パーサーと関数カタログの参照が必要であり、プロキシ層の範囲外です。
2. 私たちが列挙していない関数呼び出し以外の変更経路。 デフォルトの許可リストは、把握している17個の Postgres 管理 / ファイルシステム / DoS 関数（lo_import、lo_export、pg_read_file、pg_write_file、pg_sleep、pg_terminate_backend、dblink*、COPY … PROGRAM など）をブロックしますが、将来の Postgres バージョンに登場する新しい危険な関数は、リストが更新されるまで検出されません。
3. 動的 SQL。 ツールがある引数を受け取り、それがサーバー側でさらに SQL として連結される場合（通常は設計上の臭いですが、起こり得ます）、sqlGuard は外側のツール引数しか見ることができません。

バックストップ: データベースレベルの読み取り専用ロールが最後の防御線です。sqlGuard はベストエフォートのキーワードゲートであり、測定された95%の保証ではありません。単一の層としてではなく、層の1つとして扱ってください。 logRawArgs を有効にすると、audit は既存のファイルを chmod しますか? いいえ、JanuScope は新しい監査シンクファイルをモード 0o600(ユーザーの読み取り/書き込みのみ)で開きますが、すでに存在するファイルを chmod することはありません。監査ログが最初に logRawArgs: false(引数はハッシュ化のみ)で作成され、その後 logRawArgs: true に切り替えた場合、古いパーミッションビットがそのまま引き継がれます。raw 引数のログを有効にするときは、新しいシンクパスにローテーションして、より厳格な 0o600 が初日から適用されるようにしてください。

TypeScript / Python の MCP についてはどうですか? JanuScope は対象の MCP がどの言語で書かれているかを気にしません。MCP プロトコルである stdio JSON-RPC を介して通信します。対象は Node、Python、Go、Rust、その他何でも構いません。

CLI を使わずにプログラムから利用できますか? はい、ライブラリから runOverlay をインポートしてください。CLI はその薄いラッパーにすぎません。

自分の MCP が公開しているツールを確認するにはどうすればよいですか? Lens またはポリシーファイルに対してセットアップ診断を実行してください:

npx -y januscope check --config <name-or-path>

MCP の初期化ハンドシェイクとページ分割されたツール検出を実行し、ポリシーセレクターを確認し、ツールを呼び出さずに検出されたツールを報告します。それらの名前を JanuScope の設定で使用してください。対象は個別またはバッチの JSON-RPC メッセージを送信できます。診断オプション。

Windows ビルドはありますか? JanuScope は macOS、Linux、Windows 上の Node.js 20+ で動作します。上流の MCP 実行ファイルとオプションのデータベースドライバーは、それぞれ独自のプラットフォーム要件を保持します。SQLite はネイティブアドオンを使用します。CI は Linux 上の Node 20 と 22 をカバーし、さらにローカルの macOS パッケージチェックも行います。この変更では Windows は検証されていません。

Node のバージョンは? Node 20+ です。

mcp-remote とは何で、インストールする必要がありますか? atlassian-official、notion-official、linear-remote などの同梱の Lens は、stdio ではなく HTTPS を話すベンダーホスト型サービスであるリモート MCP をラップします。JanuScope のエンジンは stdio ネイティブであるため、これらの Lens は npx -y mcp-remote <url> を介して mcp-remote(@geelen による外部 npm パッケージ)をサブプロセスとして起動します。mcp-remote は stdio↔HTTPS の薄いブリッジであり、OAuth フローも処理します。手動でインストールする必要はなく、npx が初回使用時に取得してキャッシュし、認証状態はブリッジによって管理されます。インストールされたバージョンについては、そのドキュメントを参照してください。JanuScope 内部のネイティブ Streamable HTTP トランスポートは実装されていません。

ライセンス

JanuScope はデュアルライセンスです:

• オープンソース: GNU AGPL-3.0-only。個人利用、社内利用、および AGPL 互換でもあるオープンソースプロジェクトでは無料です。AGPL のコピーレフトはネットワークに公開されるデプロイに適用されるため、変更した JanuScope を HTTP サーフェスの背後でホストする場合は、変更内容を公開する必要があります。
• 商用: LICENSE-COMMERCIAL。商用再配布、クローズドソースのフォーク、または SaaS/OEM 提供のために AGPL のコピーレフトを解除します。価格については [email protected] までお問い合わせください。

このリポジトリに含まれるサードパーティ製ソフトウェアは、それぞれ独自のライセンスを保持します。THIRD-PARTY-LICENSES を参照してください。

コントリビューション: CONTRIBUTING.md をお読みいただき、CLA に署名してください。CLA はデュアルライセンスモデルのために必要です。

Copyright © 2026 Giancarlo Erra, Altaire Limited.