⚠️ このリポジトリは移動しました。 今後の開発は ScopeBlind/scopeblind-gateway で継続されます。
この個人のフォークは、正規のリポジトリより遅れている可能性があります。問題の報告、プルリクエスト、最新のコードについては、組織のリポジトリを使用してください。
MCPサーバー用のセキュリティゲートウェイ。デフォルトでシャドウモードのログ記録、ツールごとのポリシー、オプションのローカルEd25519レシート、および検証が容易な監査出力を提供します。
現在のCLIパス: あらゆるstdio MCPサーバーを透過プロキシとしてラップします。シャドウモードでは、すべての tools/call リクエストをログに記録し、すべてを通過させます。ポリシーファイルを追加して、ツールごとのルールを強制します。protect-mcp init を実行してローカル署名キーと設定を生成すると、ゲートウェイは署名付きレシートを発行できるようになります。
# Wrap an existing OpenClaw / MCP config into a usable pack
npx @scopeblind/passport wrap --runtime openclaw --config ./openclaw.json --policy email-safe
# Shadow mode — log every tool call, enforce nothing
npx protect-mcp -- node my-server.js
# Generate keys + config template for local signing
npx protect-mcp init
# Shadow mode with local signing enabled
npx protect-mcp --policy protect-mcp.json -- node my-server.js
# Enforce mode
npx protect-mcp --policy protect-mcp.json --enforce -- node my-server.js
# Export an offline-verifiable audit bundle
npx protect-mcp bundle --output audit.jsonRelated MCP server: protect-mcp
protect-mcpは、MCPクライアントとサーバーの間にstdioプロキシとして配置されます：
MCP Client ←stdin/stdout→ protect-mcp ←stdin/stdout→ your MCP servertools/call JSON-RPCリクエストをインターセプトし、以下を行います：
シャドウモード（デフォルト）：すべてのツール呼び出しをログに記録し、すべてを通過させます
強制モード：block、rate_limit、min_tier などのツールごとのポリシールールを適用します
オプションのローカル署名：署名が設定されている場合、構造化ログとともにEd25519署名付きレシートを発行します
その他のすべてのMCPメッセージ（initialize、tools/list、通知）は透過的に通過します。
ツールごとのポリシー — 破壊的なツールをブロックし、高コストなツールをレート制限し、最小ティア要件を付加します
構造化決定ログ — すべての決定は [PROTECT_MCP] を付けて stderr に出力されます
オプションのローカル署名付きレシート — signing.key_path を含むポリシーで実行すると生成され、.protect-mcp-receipts.jsonl に保存され、http://127.0.0.1:9876/receipts で公開されます
オフライン検証 — npx @veritasacta/verify でレシートやバンドルを検証します
アカウント不要 — ローカルキー、ローカルポリシー、ローカルプロセス
導入やユーザーへの説明の前に、以下の点にご注意ください：
署名は、単純な npx protect-mcp -- ... パスでは自動的に行われません。 そのパスはシャドウモードで決定をログに記録します。ローカル署名を行うには、npx protect-mcp init を実行してから、生成されたポリシーファイルでゲートウェイを起動してください。
ティア対応のポリシーチェックは有効ですが、マニフェストの承認はデフォルトのCLI/stdioパスには組み込まれていません。 ホスト統合がプログラムで承認APIを呼び出さない限り、CLIはセッションを unknown と見なします。
資格情報設定は、現在、環境変数ベースの資格情報参照を検証し、ログ/レシートに資格情報ラベルを記録します。 任意のstdioツールへの呼び出しごとの汎用的な注入はアダプター固有であり、デフォルトのプロキシパスでは実行されません。
外部PDPアダプターと監査バンドルヘルパーは、エクスポートされたユーティリティとして存在します。 これらは、デフォルトのCLIパスにはまだ完全には組み込まれていません。
{
"default_tier": "unknown",
"tools": {
"dangerous_tool": { "block": true },
"admin_tool": { "min_tier": "signed-known", "rate_limit": "5/hour" },
"read_tool": { "require": "any", "rate_limit": "100/hour" },
"*": { "rate_limit": "500/hour" }
},
"signing": {
"key_path": "./keys/gateway.json",
"issuer": "protect-mcp",
"enabled": true
},
"credentials": {
"internal_api": {
"inject": "env",
"name": "INTERNAL_API_KEY",
"value_env": "INTERNAL_API_KEY"
}
}
}フィールド | 値 | 説明 |
|
| このツールを明示的にブロックする |
|
| 基本的なアクセス要件 |
|
| ホストが承認状態を設定している場合に必要な最小ティア |
|
| レート制限（例: |
ツール名は完全に一致させる必要があり、"*" をワイルドカードとして使用できます。
claude_desktop_config.json に追加します：
{
"mcpServers": {
"my-protected-server": {
"command": "npx",
"args": [
"-y", "protect-mcp",
"--policy", "/path/to/protect-mcp.json",
"--enforce",
"--", "node", "my-server.js"
]
}
}
}同じパターンです。サーバーコマンドを protect-mcp でラップしたものに置き換えてください。
protect-mcp [options] -- <command> [args...]
protect-mcp init
Commands:
init Generate Ed25519 keypair + config template
status Show decision stats and local passport identity
digest Generate a local human-readable summary
receipts Show recent persisted signed receipts
bundle Export an offline-verifiable audit bundle
Options:
--policy <path> Policy/config JSON file
--slug <slug> Service identifier for logs/receipts
--enforce Enable enforcement mode (default: shadow)
--verbose Enable debug logging
--help Show helpこのライブラリは、デフォルトのCLIパスにはまだ組み込まれていないプリミティブも公開しています：
import {
ProtectGateway,
loadPolicy,
evaluateTier,
meetsMinTier,
resolveCredential,
initSigning,
signDecision,
queryExternalPDP,
buildDecisionContext,
createAuditBundle,
} from 'protect-mcp';以下を追加したい場合に使用してください：
セッション開始前のマニフェスト承認
外部PDP（OPA、Cerbos、または汎用HTTP Webhook）
カスタムの資格情報仲介統合
独自のレシートストア周辺の監査バンドルエクスポート
すべてのツール呼び出しは、構造化されたJSONを stderr に出力します：
[PROTECT_MCP] {"v":2,"tool":"read_file","decision":"allow","reason_code":"observe_mode","policy_digest":"none","mode":"shadow","timestamp":1710000000}署名が設定されている場合、署名付きレシートが続きます：
[PROTECT_MCP_RECEIPT] {"v":2,"type":"decision_receipt","algorithm":"ed25519","kid":"...","issuer":"protect-mcp","issued_at":"2026-03-22T00:00:00Z","payload":{"tool":"read_file","decision":"allow","policy_digest":"...","mode":"shadow","request_id":"..."},"signature":"..."}CLIで検証：npx @veritasacta/verify receipt.json
ブラウザで検証：scopeblind.com/verify
このパッケージは、自己完結型の監査バンドル用のヘルパーをエクスポートします：
{
"format": "scopeblind:audit-bundle",
"version": 1,
"tenant": "my-service",
"receipts": ["..."],
"verification": {
"algorithm": "ed25519",
"signing_keys": ["..."]
}
}収集した独自の署名付きレシートに対して createAuditBundle() を使用してください。
シャドウファースト。 何かを強制する前に、エージェントが何をしているかを確認します。
レシートはダッシュボードのみのログに勝る。 署名されたアーティファクトは、独立して検証可能であるべきです。
主張を厳密に保つ。 デフォルトのCLIパスは、長期的なアーキテクチャがサポートするすべてをまだ実行しているわけではありません。
既存の認証の上に重ねる。 制御と証拠を追加するためだけに、スタックを入れ替えないでください。
protect-mcpに同梱されており、それぞれが実際の攻撃を防ぎます：
ポリシー | インシデント | OWASPカテゴリ |
| CVE-2025-6514: MCP OAuthプロキシハイジャック (437K環境) | A01, A03 |
| 自律型Terraformエージェントが本番環境を破壊 | A05, A06 |
| 作成されたGitHub Issueによるプロンプトインジェクション | A01, A02, A03 |
| アウトバウンドツール悪用によるエージェントのデータ窃取 | A02, A04 |
| 不正な金融取引 | A05, A06 |
npx protect-mcp --policy node_modules/protect-mcp/policies/clinejection.json -- node server.jsOWASP Agentic Top 10の完全なマッピング：scopeblind.com/docs/owasp
OPA、Cerbos、Cedar (AWS AgentCore)、および汎用HTTPエンドポイントをサポートしています：
{
"policy_engine": "hybrid",
"external": {
"endpoint": "http://localhost:8181/v1/data/mcp/allow",
"format": "cedar",
"timeout_ms": 200,
"fallback": "deny"
}
}IETF Internet-Draft: draft-farley-acta-signed-receipts-00 — マシン間アクセス制御のための署名付き決定レシート
特許状況: 決定レシート（構成可能な開示、ツール呼び出しゲートウェイ、エージェントマニフェスト、ポータブルIDを含む）に関するオーストラリアの仮特許4件が申請中 (2025-2026)
検証: MITライセンス — npx @veritasacta/verify --self-test
MIT — 制限なしで自由に使用、変更、配布、構築が可能です。
scopeblind.com · npm · GitHub · IETF Draft
Delete a file from the filesystem
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose that deletion is irreversible or mention behavior for missing paths or directories, which is critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but could be improved by including context about irreversibility without significant length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema or annotations, the description lacks completeness: no mention of return values, errors, or required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description 'File path to delete' is already clear; the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'file from the filesystem', distinguishing it from sibling tools like read_file (read) and write_file (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy the application to production
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Deployment reason | |
| environment | Yes | Target environment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits like destructiveness, auth requirements, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (5 words), but underspecified – conciseness should not sacrifice necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return values, side effects, or deployment process outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'deploy the application to production' – clear verb and resource, but slightly misleading as schema allows staging also. No confusion with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or when-not-to-use mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions reading without specifying encoding, size limits, existence requirements, or return format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single-sentence description that is front-loaded and efficient with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simplicity, description lacks details on return format, error handling, and behavioral constraints, which are critical for an agent invoking a file read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'path' described as 'File path to read'; description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'read' and resource 'contents of a file', distinguishing it from sibling tools like write_file and delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by the name and description but lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web for information
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks details on behavior such as rate limits, result format, or limitations, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but fails to include necessary details, balancing brevity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description does not adequately cover what the agent needs to know for successful use, such as result types or response details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'query' with a schema description, and the tool description adds no additional meaning beyond what the schema already provides; high schema coverage baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search the web for information' clearly states the verb and resource, and it distinguishes from siblings (file operations and deploy) which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, and no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to write | |
| content | Yes | Content to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose important behavioral traits such as whether the file is overwritten, permissions required, or error handling. Without annotations, the description carries the full burden, and it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, to-the-point sentence with no wasted words. It earns its place by conveying the core action concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file write tool, the description lacks completeness. It does not mention return values, overwrite behavior, or any constraints, making it less useful for an AI agent to fully understand the tool's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the description adds no extra meaning. Baseline 3 is appropriate; the schema already documents path and content adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Write content to a file' clearly states the verb 'Write' and the resource 'content to a file', distinguishing it from sibling tools like read_file and delete_file. However, it does not specify whether it overwrites or appends, which would add more precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. An explicit mention of use cases or exclusions (e.g., when to use deploy instead) is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
delete_filedeployread_fileweb_searchwrite_fileScored across 5 tools
Each tool targets a distinct action: file operations (delete, read, write), deployment, and web search. There is no overlap or ambiguity between them.
Most tools follow verb_noun pattern (delete_file, read_file, write_file, web_search), but 'deploy' lacks a noun, breaking the consistent pattern slightly.
5 tools is a reasonable count, but the mix of file management, deployment, and web search seems odd for a single server scope.
The tool set lacks obvious necessary operations for any single domain: e.g., no update for files, no environment or config for deployment, making it incomplete for a coherent purpose.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
