GxP Gateway Audit について
GxP Gateway Auditは、MCPおよびHTTP(S) API、ゲートウェイ、LLMエンドポイントの呼び出しを監査するプロキシです。GLPや規制対象ワークフローの支援を目的とし、顧客のインフラ内にハッシュチェーン形式の監査記録を保持します。
主な機能
- 01ハッシュチェーン形式のJSONL記録
- 02MCPおよびHTTPSリクエストの仲介
- 03ツールとルートの許可・拒否ポリシー
- 04ロールベースアクセスと任意の承認
- 05監査チェーン検証とJSON出力
- 06設定の初期化と検証
活用シーン
- 01MCPホストとサーバー間の呼び出し監査
- 02APIおよびLLMエンドポイント通信の記録
- 03書き込み理由と承認制御の適用
- 04レビュー時の監査ログ完全性の検証
MCP 対応
MCPホストと上流MCPサーバー間のstdioプロキシとして動作し、listen設定時にはHTTPSも提供します。拒否や失敗を含む仲介呼び出しをハッシュチェーン形式の監査記録に保存します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
uvx mcp-glp-audit-proxyGLP_CONFIGPath to the proxy JSON config (upstreams, policy, audit file).GLP_PRINCIPAL_IDAuthenticated human id for this process. Stdio identity comes from the environment.GLP_PRINCIPAL_NAMEPrinted name of the human principal.GLP_PRINCIPAL_ROLEOne of operator, approver, qa, admin.ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
mcp-name: io.github.antonio-castellon/mcp-glp-audit-proxy
mcp-glp-audit-proxy
GxP Gateway Audit(パッケージ mcp-glp-audit-proxy)は、MCP および HTTP(S) API、ゲートウェイ、LLM エンドポイントを監査します。コミュニティ版 v0.4.0 です。パッケージ名、コマンド名、MCP Registry ID は mcp-glp-audit-proxy のままです。0.2.0 以降の変更点は CHANGELOG.md に記載されています。
リスナーとすべてのリモート URL は、TLS 1.3 を使用する HTTPS です。プレーンな HTTP は拒否されます。listen オブジェクトがない場合も、プロセスはホストと MCP サーバー間の stdio MCP プロキシとして動作します。
GLP/21 CFR Part 11/EU GMP Annex 11 のワークフローをサポートするように設計されています。データはお客様のインフラストラクチャ内に保持されます。このパッケージはオープンコアです。署名付きチェックポイント、WORM ストレージ、PDF/CSV レポート、IQ/OQ パック、SSO/OAuth は Pro 機能であり、このリポジトリには含まれていません。個人の Part 11 電子署名は対象外です。コミュニティ版ではハッシュチェーンにより改ざんを検知できますが、署名はされません。署名機能は Pro 版です。
インストール
Python 3.11 以降が必要です。
pip install mcp-glp-audit-proxy
チェックアウトからインストールする場合:
pip install -e ".[dev]"
mcp 依存関係は >=2.2.0,<3 に固定されています。この下限は GHSA-84m7-p3x7-pcfv の影響範囲外です(影響を受ける範囲は mcp >=1.8.0,<1.30.0 および >=2.0.0,<2.2.0 です)。古い SDK ではプロセスの起動が拒否されます。
実行
export GLP_PRINCIPAL_ID=operator-1
export GLP_PRINCIPAL_NAME="Ada Analyst"
export GLP_PRINCIPAL_ROLE=operator
mcp-glp-audit-proxy --config config.json
stdio の ID は環境変数(GLP_PRINCIPAL_ID、GLP_PRINCIPAL_NAME、GLP_PRINCIPAL_ROLE)から取得します。設定に listen オブジェクトがない場合、プロセスは stdin から改行区切りの JSON-RPC を読み込み、stdout に書き込み、ソケットは開きません。listen が設定されている場合、同じコマンドが HTTPS を提供し、stdio は読み込みません。Cursor のスニペットは mcp.json にあります。完全な設定例は config.example.json にあります。設定リファレンスは docs/manual-guides/README.md です。
plugins.storage、plugins.signer、plugins.reporters、plugins.auth はエントリーポイントを選択します。デフォルトはそれぞれ jsonl、unsigned、json と text、env です。env は GLP_PRINCIPAL_* または設定ファイルからプリンシパルを取得します。これは ID プロバイダーではありません。不明なプラグイン、または宣言されたライセンス機能が有効になっていないプラグインは、起動を拒否します。ファクトリーは呼び出されません。プロキシは別のバックエンドにフォールバックしません。docs/PLUGINS.md を参照してください。
チェーンを検証し、検索可能な JSON エクスポートを書き込みます(チェーンが検証されない場合、エクスポートはスキップされます)。
mcp-glp-audit-proxy-verify data/audit.jsonl --json-export exports/audit.json
mcp-glp-audit-proxy-verify data/audit.jsonl --tool excel__write_cell --status ok
mcp-glp-audit-proxy-verify data/audit.jsonl --print-head
--print-head は seq=<n> entry_hash=<64 hex> を出力します。この行をチケット、メール、または LIMS レコードにコピーしてください。後で --expect-head <seq>:<entry_hash> または --expect-head-file で確認できます(ファイルには同じ行を記載できます)。チェーンの先端が異なる場合、コマンドは 1 で終了します。サイドカー data/audit.jsonl.head により、末尾の完全な行が切り詰められている場合は検証に失敗します。ログとサイドカーの両方を編集できる人は、それらを一緒に変更できます。外部にコピーしたものが制御手段となります。Community はハッシュチェーンによって改ざんを検知できますが、署名されていません。署名機能は Pro です。--pubkey は、ライセンス対象の署名プラグインに固定された公開鍵ファイルを渡します。ライセンス対象の署名プラグインがない場合、検証に失敗します。その署名プラグインを読み込むには、--licence と --client-id を渡すか、GLP_LICENCE_PATH と GLP_CLIENT_ID を設定してください。ライセンスパスが指定されていない場合、ライセンスファイルは読み込まれません。ライセンスが見つからないか無効な場合、2 で終了します。署名なしのチェックポイントがデフォルトのままであり、署名済みとして扱われることはありません。ログと .head サイドカーは、開く際にモード 0600 になります。ストアによって作成されるログディレクトリはモード 0700 になります。
設定
init は監査ログのパス、ツールの許可リスト、プリンシパル(ID、名前、ロール)、保持プロファイル、法的保全について尋ねます。起動時に使用されるものと同じローダーが受け入れる JSON 設定を書き込み、モードは 0600 に設定されます。プロンプトとファイルの内容は ASCII です。ウィザードはネットワーク接続を開きません。保存先がすでに存在する場合、上書きの質問に「はい」と答えない限り変更されません。
mcp-glp-audit-proxy init
mcp-glp-audit-proxy init /srv/glp/config.json
デフォルトのパスは、GLP_CONFIG が設定されている場合はその値、それ以外の場合は config.json です。これはプロキシが読み込むファイルと同じです。
config check は設定を読み込み、読み込めない場合は平易な言葉でエラーを出力します。ファイルを読み込めた場合、プロセスは 0 で終了し、読み込めなかった場合は 1 で終了します。GLP_* による上書きを含め、起動時と同じローダーを使用します。デフォルトのパスは init と同じです。
mcp-glp-audit-proxy config check
mcp-glp-audit-proxy config check config.json
ライセンス対象のプラグインは、mcp_glp_audit_proxy.wizard エントリーポイントを通じて質問と検証ステップを追加できます。ライセンスのないプラグインは呼び出されず、何も追加しません。docs/PLUGINS.md を参照してください。
ライセンスファイルはローカルにあります。ネットワーク呼び出しはありません。LM1 は 3 行で構成されます。LM1、本文を Base64 でエンコードしたもの、生バイト列に対する RSA-2048 PSS 署名を Base64 でエンコードしたものです。LM2 も 3 行で構成されます。LM2、本文を Base64 でエンコードしたもの、生バイト列に対する 64 バイトの Ed25519 署名を Base64 でエンコードしたもので、本文はコンパクトなソート済み JSON でなければなりません。LM1、および features リストのない LM2 は、インストール済みのライセンス対象プラグインが宣言する機能を有効にします。features を列挙した LM2 ファイルは、列挙された名前のみを有効にします。それ以外のファイルは拒否されます。本番環境の公開鍵は release_trust.json にあり、mcp_glp_audit_proxy.trust の trusted_keys() によって読み込まれます。フィンガープリントはマシン ID ではありません。詳細は docs/PLUGINS.md を参照してください。
記録される内容
拒否や失敗を含む、仲介されたすべての呼び出しは、追記専用の JSONL ファイルに 1 つの JSON オブジェクトとして記録されます。各行は RFC 8785 の正規化 JSON です。entry_hash は、entry_hash を削除したオブジェクトの SHA-256 です。prev_hash は前のエントリーを示します(最初のエントリーでは 64 個のゼロ)。hash_algo と canonicalization はエントリーに保存されます。オープンスキーマは schema/audit-record.schema.json です。クロスランゲージのテストベクトルは schema/jcs-test-vectors.json にあります。
フィールドには、呼び出し元(principal の ID、名前、ロール)、ツール、入力、出力、UTC タイムスタンプと utc_offset、プロトコルバージョン、任意のセッション ID、レコードクラス(gxp_data、access、technical、config)、書き込み理由、前のハッシュが含まれます。
スキーマ 1.3.0 では、transport(stdio または https)、channel(mcp または https)、flow(mcp2mcp、mcp2api、api2mcp、api2api、mcp2llm、api2llm、またはローカルレコードの場合は null)、http、arguments_sha256、result_sha256 が保存されます。http オブジェクトには、メソッド、ルートテンプレート、クエリ文字列を除いたパス、保持されたヘッダー、削除された認証情報ヘッダーの名前、本文の SHA-256、body_mode、保存された本文、ステータス、latency_ms、kind(api、llm、mcp)が含まれます。クエリ文字列は転送されますが、保存されません。1.0.0 および 1.1.0 の行には、後から追加されたキーは含まれません。古い行も同じチェーン内で有効なままです。
GxP 監査証跡はこのファイルです。Python の logging ロガー mcp_glp_audit_proxy.technical は、メソッド、ステータス、レコードクラスを stderr に書き込みます。これは監査レコードではありません。引数はそこには書き込まれません。
ポリシー
- 許可リストと拒否リストでは、公開されるツール名(
excel__write_cell)に対してシェル形式のグロブを使用します。拒否リストが優先されます。許可リストが空の場合、すべての上流ツールが拒否されます。 - ロールは
operator、approver、qa、adminです。上流ツールを呼び出せるのはoperatorのみです。qaは監査記録(glp_verify_chain、glp_search_audit、glp_export_audit)の読み取り専用です。approverは承認を記録し、監査記録を読み取れます。adminはポリシーを変更して監査記録を読み取れますが、上流ツールは呼び出せません。 - 監査を無効にすることはできません。
audit_enabled: falseを指定したglp_update_policyは拒否され、記録されます。 - 書き込みツール(
write_toolsに一致する名前)では、デフォルトで理由が必要です。理由は_meta["io.github.antonio-castellon/reason"]または引数_glp_reasonで指定します(上流への呼び出し前に取り除かれます)。 - 人による承認を有効にすると、
approverロールの別の担当者が意味をapprovedとして記録するまで、書き込みは保留されます。reviewedはステータスreviewedとして保存され、書き込みの実行は許可しません。スキーマ 1.1.0 より前に書き込まれたログでは、この判断が意味reviewed、ステータスapprovedとして表示される場合があります。それらの行も検証に成功しますが、書き込みの実行は許可しません。rejectedは書き込みを拒否します。承認は一度だけ使用でき、正規化された{tool, arguments}の SHA-256 に紐付けられ、有効期限があります(デフォルトは 3600 秒)。require_approval_for_writesがその呼び出しより前に無効にされていた場合でも、一致する承認を提示した書き込みが成功すると、その承認は使用済みとして記録されます。上流の呼び出しに失敗した場合、承認は使用済みになりません。記録ラベルはapprovalです。これは電子署名ではありません。 - HTTP ルートでは、
http_allowとhttp_denyという別の許可リストと拒否リストを使用します。各項目はMETHOD /pathの形式で、パスにはシェル形式のグロブを使用します(GET /v1/studies/*)。拒否リストが優先されます。http_allowが空の場合、すべての HTTPS ルートが拒否されます。MCP ツール呼び出しは拒否されません。HTTPS ルートを呼び出せるのはoperatorのみです。 audit.body_modeはhash_only(新しい設定のデフォルト)、redacted、fullのいずれかです。どの値を使用するかは、お客様と QA が決定します。body_modeは HTTPS の本文、および MCP ツール呼び出しの引数と結果に適用されます。未加工のリクエスト本文の SHA-256 は常に記録され、MCP ツールの引数と結果の SHA-256 も同様に記録されます。hash_onlyでは本文のバイト列も MCP ペイロードも保存されません。redactedでは、audit.redact_pathsにあるパスを***に置き換えた JSON を保存します(JSON ではない本文は平文で保存されません)。fullでは、リクエストの解析済み JSON または UTF-8 テキストをハッシュチェーン付きレコード内に保存し、レスポンスのテキストもresponse_sha256の隣にresponse_bodyとして保存します。ログファイルのモードは 0600 です。UTF-8 ではないバイナリはハッシュ化され、リクエスト本文としては保存されません。すべてのモードで、レスポンス本文はクライアントに返されます。Content-Length がない書き込みリクエスト、または Transfer-Encoding を含む書き込みリクエストは、411 で拒否され、記録されます。hash_onlyモードとredactedモードでは、ペイロードが存在し改変されていないことを監査記録で証明できますが、内容は確認できません。内容の記録は対象システムで保持する必要があります(OECD No. 17 para 80)。- デフォルトの本文サイズ上限は 1048576 バイトです。
audit.max_body_bytesは最大 8388608 まで引き上げられます。これを超える本文はステータス 413 で拒否され、転送されず、body_sha256は null として記録されます。ストリーミングは 0.4.0 ではサポートされません。Content-Length のない GET と HEAD の本文は空です。Content-Length のない書き込み、または Transfer-Encoding を含む書き込みは、411 で拒否され、記録されます。 - HTTPS の書き込み(
POST、PUT、PATCH、DELETE)では、require_reason_for_writesが true の場合、X-Audit-Reasonヘッダーが必要です。任意の承認には同じエンジンが使用されます。紐付けに使うハッシュは正規化された{tool, arguments}のもので、toolはhttp:METHOD /route-template、argumentsはbody_sha256と具体的なパスです。承認者はglp_approveまたはPOST /_glp/approveを呼び出します。reviewedとrejectedは書き込みの実行を許可しません。 - デフォルトではフェイルクローズです。呼び出しを転送する前にストアが検査されます。上流の呼び出し成功後の追記に失敗した場合、上流のペイロードはホストに返されません。拒否された呼び出しと失敗した呼び出しも記録されます。上流ですでに書き込みが適用された可能性がある場合は、
docs/RECONCILIATION_SOP.mdに従ってください。
プロトコル
このプロキシは、ハンドシェイク方式の MCP リビジョン(2024-11-05、2025-03-26、2025-06-18、2025-11-25、initialize を使用)と、仕様 2026-07-28(server/discover を使用し、initialize もセッションもなし)の両方に対応しています。セッション ID は、そのリビジョンでセッション ID がある場合にのみ記録されます。上流プロトコルの auto は server/discover を試し、失敗した場合は 2025-11-25 の initialize にフォールバックします。
公開されるツール名は server__tool です。リソース URI には server: がプレフィックスとして付加されます。認証情報を含む _meta キーは除去され、キー名はログに記録されますが、値は保存も転送もされません。上流の stdio には、MCP SDK の安全な環境変数許可リストと、構成内の env ブロックが渡されます。
規制要件への対応
mcp-glp-audit-proxy は、以下の監査証跡要件への対応を支援するよう設計されています。要件を満たすかどうかは、引き続き SOP とレビューにも左右されます。条項ごとの対応表は docs/COVERAGE.md にあります。規範と検証ログは docs/STANDARDS.md にあります。
HTTPS の ID 検証には 3 つのモードがあります。mtls は、クライアント証明書の SHA-256 フィンガープリントをプリンシパルに対応付けます。bearer は、プライベートファイルから 1 つの静的トークンを読み込み、トークンをログや記録に書き込まずに照合します。Linux と macOS では、このファイルのモードを 0600 にする必要があります。Windows では、起動時に NTFS ACL を読み取り、現在のユーザー、SYSTEM、BUILTIN\Administrators のみにアクセスを許可します。Everyone、Users、Authenticated Users、またはその他のプリンシパルにアクセス権がある場合、起動を拒否し、icacls <file> /inheritance:r /grant:r "%USERNAME%:R" SYSTEM:F Administrators:F を出力します。mtls_and_bearer では両方が必要です。認証なしのモードも、平文リスナーもありません。共有 bearer はゲートとして機能しますが、固有のユーザー ID ではありません。FDA のデータ完全性に関する質問と回答(2018)には、「ログイン認証情報が共有されている場合、ログインを通じて個人を特定することはできません」とあります。WHO TRS 1033 11.9 では、共有ログインまたは汎用ユーザーアクセスを使用すべきではないとされています。オプションの end_user_header は、そのゲートを通過した後に限り、かつヘッダー値が構成済みのユーザー ID である場合にのみ受け入れられます。
このパッケージは、21 CFR 11.10(d)「認可された個人にシステムアクセスを制限すること」と、EU GMP Annex 11(2011)の第 12.1 項および第 12.4 項への対応を支援するよう設計されています。第 12.1 項:「コンピューター化システムへのアクセスを認可された者に制限するため、物理的および/または論理的な管理策を設ける必要があります。」第 12.4 項:「データおよび文書の管理システムは、データの入力、変更、確認、または削除を行うオペレーターの身元を、日時を含めて記録するよう設計する必要があります。」21 CFR 11.300 は、電子署名に使用される識別コードおよびパスワードの管理策を対象としています。電子署名は対象範囲外のため、11.100(a) と同様に 11.300 も対象範囲外です。これらの要件に適合するモードは、ユーザーごとの帰属を可能にする方式です。つまり、個人ごとに 1 つのクライアント証明書を使うか、認証済みゲートウェイからエンドユーザーヘッダーを渡します。共有 bearer とクライアントが指定するヘッダーの組み合わせの強度は、そのユーザーを確認したゲートウェイの強度に依存します。
| フレームワーク | プロキシが支援する内容 | エディション |
|---|---|---|
| OECD GLP No. 17 (3.4) / Swiss GLPV Annex 2 | 常時稼働する追記専用の監査証跡、誰が/何を/いつ/なぜ行ったかの記録、管理者専用の設定、QA 読み取り専用ロール、スイスの10年間保存プロファイル | コミュニティ版のコア機能。WORM 保存と PDF レポートは Pro |
| FDA 21 CFR Part 11 | コンピューター生成のタイムスタンプ付きハッシュチェーン監査証跡(11.10(e))、改ざん検知、完全なコピー、権限確認。コミュニティ版ではハッシュチェーンによって改ざんの痕跡を検出できますが、署名はされません。署名機能は Pro です。個人による Part 11 電子署名は対象外です。承認は電子署名ではありません | コミュニティ版のコア機能。レポート、チェックポイント署名、SSO は Pro |
| EU GMP Annex 11 (2011; 2025 draft) | 変更理由を含む監査証跡、ロール、タイムゾーン、無効化できず、改ざんの痕跡を検出できる監査証跡(ハッシュチェーン)、glp_search_audit / glp_export_audit による検索可能なエクスポート、アクセスログ | コミュニティ版のコア機能。レビュー用ツールと非アクティブ時のログアウトは Pro |
| MHRA / PIC/S PI 041-1 / WHO TRS 1033 | ALCOA+ データ完全性、職務の分離、各レコードに付随するメタデータ、真正なコピーのエクスポート | コミュニティ版のコア機能。署名付きマニフェストとバリデーションパックは Pro |
| ISPE GAMP 5 / FDA CSA | サプライヤー文書、カテゴリー4の構成済みコンポーネント案、機械可読なテスト証拠 | Pro(バリデーションパック) |
| EU AI Act Art. 12, 19, 26(6) | 顧客の AI システムが高リスクに該当する場合に、Art. 12、19、26(6)への対応を支援できるよう設計されています。プロキシは、プロバイダーまたはデプロイヤーが保持できる自動生成ログを提供できます。これだけで AI システムが Art. 12 を満たすわけではありません。デフォルトで6か月の保存期間の下限が適用されます。ただし、特にデータ保護法などの EU 法または国内法に別段の定めがある場合は、AI Act の最低要件が適用されます。高リスク用途に該当するかどうかは、顧客が分類します。http://data.europa.eu/eli/reg/2024/1689/oj を参照してください | コミュニティ版 |
| Crypto and time (RFC 8785, SHA-256, Ed25519/ECDSA, RFC 3161, eIDAS/ZertES, TLS 1.3) | 正規化ハッシュ処理と暗号化された通信 | ハッシュチェーンと TLS はコミュニティ版、署名とタイムスタンプは Pro |
| MCP authorization, OWASP LLM/Agentic | トークンのパススルーなし、ツールの許可リスト/拒否リスト、書き込みツールの実行前承認、OAuth 2.1 | 許可リストとパススルーなしはコミュニティ版、OAuth/SSO は Pro |
| ISO/IEC 42001, NIST AI RMF | AI ガバナンスと監視のためのイベントログ証拠 | コミュニティ版(補足的な証拠のみ) |
デフォルトの保存期間はスイスの GLP プロファイルに基づき、試験完了後10年間です。ただし、最低でも6か月間保存します。minimum プロファイルでは年数を短縮できますが、6か月未満にはできません。法的保全フラグが設定されている場合、廃棄は拒否されます。JSONL バックエンドには削除機能がありません。保存期間中の WORM 適用は Pro バックエンドの機能です。
制限事項
このプロキシは対象システムの監査証跡を補完するものであり、置き換えるものではありません。ゲートウェイのアクティビティを記録し、監査証跡のレビュー(検索とエクスポート)を支援するよう設計されています。変更前後の値は記録しません。
require_reason_for_writes をオフにすると、理由の記録が行われなくなります(OECD No. 1 8.3.5、Annex 11 sec. 9、21 CFR 58.130(e))。この変更自体は記録されます。
Community の JSONL は改ざんの検知が可能ですが、改ざんを防止するものではありません。ホスト管理者はファイルを削除できます。検知には verify と外部アンカリングまたはバックアップが必要です(WHO TRS 1033 11.15/11.16、OECD No. 22 6.14)。
システム自身で監査証跡を保持できない場合は、正当性を示し、文書化したうえで、期間を限定してアドオン監査証跡を使用してください(WHO TRS 1033 11.12、OECD No. 22 6.13)。GxP で使用する場合は、require_ntp を true に設定してください。
記録は追記専用で、ハッシュチェーンで連結されています。記録が欠落または編集されると、重大なアラートとともにプロキシが停止します(GxP のフェイルクローズ)。Community には、インプレース消去や暗号シュレッディングの機能はありません。消去(GDPR Art. 17)は顧客の手順に従って行います。セグメントを閉じ、アーカイブ済みのコピーを処理して、新しいセグメントを開始してください。body_mode full を選択する前に、消去請求と法的な保持義務(Art. 17(3)(b)、(c)、(d))を比較検討してください。消去可能なコンテンツをチェーンに含めないようにするには、hash_only または redacted を使用してください。
Community はログを保存時に暗号化しません。ファイルへのアクセス権は所有者のみに制限されます(0600、または Windows では所有者のみの ACL)。特に body_mode full の場合は、ディスクまたはボリュームの暗号化を使用してください。
body_mode はグローバル設定であり、ルートごとの設定ではありません。full は、保持期間全体にわたってリクエストとレスポンスの本文を保存します(健康データが含まれる場合があります。スイス GLP プロファイルでは 10 年以上)。
保持プロファイルは最低保持期間を定めるものであり、プロキシが記録を削除することはありません。保持期間終了後の廃棄は、顧客の手順に従って行います。
フェイルクローズによる停止は、AI ツールのトラフィックを中断させます。これを緊急時対応計画に含めてください。
listen.auth_failure_limit が設定されていない限り、認証失敗時のロックアウトはオフです。regulatory-report では、この項目を未設定として表示し、OECD No. 25 para 14 および Annex 11 draft 2025 11.7(草案であり、施行されていません)を示します。これにより、QA は有効にするかどうかを判断できます。デフォルトではロックアウトはありません。
ID やロールを含む設定変更は、次回の監査時または起動時に記録されます(config_changed)。変更は再起動時にのみ確認できます。require_reason_for_writes がオンの場合は、--change-reason または GLP_CHANGE_REASON を指定してください。指定しなくてもプロセスは起動しますが、記録の理由は null になります。
すべての監査記録には、どの body_mode でも個人データが含まれます。主体の ID と名前、ロール、クライアント証明書のフィンガープリント、end_user_header を使用している場合はエンドユーザー ID、リクエストパス(ID が含まれる場合があります)、保持されるリクエストヘッダー(user-agent など)、タイムスタンプです。hash_only は匿名化ではありません。短い本文や推測しやすい本文のソルトなし SHA-256 は、推測によって照合できる場合があります。顧客は管理者として、適法な根拠、body_mode、redact_paths、保持期間を決定します。監査記録内の個人データを参照してください。
GLP 試験施設でのバリデーション
GLP 試験施設では、プロキシは GLP 関連記録を転送して保存するため、それ自体がコンピューター化システムであり、試験施設によるバリデーションの対象となります(AGIT V4.0 category C:バリデーションを要する複雑なシステム)。オープンな OQ ランナー、要求事項トレーサビリティマトリックス、規制設定レポート、CHANGELOG は、そのバリデーションへの入力資料であり、バリデーションそのものではありません。
監査証跡レビュー(AGIT 11.2):レビュー SOP で glp_search_audit、glp_export_audit、verify を使用してください。クローズ済みパッケージのアーカイブについては、docs/ARCHIVING.mdで説明しています。
システム要件
CI でテスト済みの Python 3.11、3.12、3.13 が必要です。CI では Linux をテストします。同じソースは macOS と Windows でも動作するように記述されています。ホストの時計を同期(NTP)し、不正な変更から保護してください。GxP で使用する場合は、require_ntp を true に設定してください。
ディスク:hash_only レコードは約 1 KB です。redacted と full はペイロードに応じて増加します。保持する呼び出し数を掛けたサイズを見込み、1,000 回の呼び出しにつきレコード 1 件分、およそ 1,000 倍の増加を想定してください。ログとその head ファイルは、同じバックアップ対象ボリュームに置く必要があります。片方だけを復元すると、セグメントを閉じるまで起動が拒否されます。
規制構成レポート
mcp-glp-audit-proxy regulatory-report --config config.json は構成のみを読み取り、グループごとに、その構成が各対応条項をサポートしているかどうかを出力します。サービスは起動せず、ログを開かず、ネットワークも使用しません。--format md または json、--out FILE、--profile swiss_glp、--applies glp,part11,ai_high_risk,gdpr_bodies を指定できます。--fail-on-gap を指定すると、チェック対象の行がサポートされていない場合に終了コード 1 を返します。最終評価はお客様の QA が行います。対応マップは src/mcp_glp_audit_proxy/data/regulatory_map.json で、docs/COVERAGE.md と照合されています。
archive-manifest は、ログ、head サイドカー、セグメントファイル、および存在する場合はアラートファイルの索引を書き出します。verify --manifest は後続のコピーをチェックします。archive-transfer と verify --manifest --received-by は、そのパッケージの管理履歴を記録します。docs/ARCHIVING.md を参照してください。日常運用、バックアップ、独立した head チェックについては、docs/OPERATIONS.md を参照してください。
review <audit_file> --out FILE は、例外レビュー用レポートを書き出します(--format json、md、または csv)。CSV は期間内のレコードごとに 1 行です。レポートに本文はコピーされません。
オフラインの verify、verify --json-export、archive-manifest、regulatory-report、review は、稼働中の監査ログに追記しません。各出力には run ブロックが含まれます。--run-log FILE を指定すると、同じブロックを別のハッシュチェーンログに追記します。そのログは verify-run-log でチェックしてください。稼働中のゲートウェイ経由で行われたエクスポート(glp_export_audit)は、引き続き稼働中の監査証跡に記録されます。
コミュニティ版と Pro
このリポジトリはコミュニティ版です。Pro はライセンス制の有料サービスとして提供しています。詳細については [email protected] までお問い合わせください。
Pro では、SQL および S3 WORM バックエンド、Ed25519 および ECDSA 署名、RFC 3161 タイムスタンプ、PDF および CSV 形式の監査レポート、IQ/OQ バリデーションパック、SSO が追加されます。また、mcp-advanced-excel 向けの GLP Lab Data Pack も含まれており、同じオフラインライセンスキーでロックを解除できます。無料の mcp-advanced-excel サーバーは、ラボのスプレッドシートを読み書きします。Data Pack ではその上に、すべての結果をソースファイルに結び付ける来歴ハッシュ、一般的なラボのエクスポート向け計測機器テンプレート、高度な LOD/LOQ 計算とモル単位変換、複数ファイルの一括処理、Ed25519 による署名付き出力など、GLP ラボに必要な機能が追加されます。
マークは、そのエディションに該当機能が含まれていることを示します。Pro にはコミュニティ版のすべての機能が含まれます。マークだけでは制限が分からない場合に限り、注記を追加しています。該当機能がないコミュニティ版のセルは、通常の :x: です。この表から Pro のソースツリーにリンクすることはありません。
| 機能 | コミュニティ版(このリポジトリ) | Pro(ライセンスサービス) |
|---|---|---|
| 2 世代のプロトコルに対応するプロキシコア | :white_check_mark: | :white_check_mark: 接続して使用し、フォークしません |
| 追記専用 JSONL ハッシュチェーン | :white_check_mark: | :white_check_mark: SQL/S3 にも対応 |
| PostgreSQL / MSSQL への追記専用保存 | :x: | :white_check_mark: |
| S3 Object Lock | :x: | :white_check_mark: |
| 検証 CLI と検索可能な JSON エクスポート | :white_check_mark: | :white_check_mark: |
| プレーンテキスト形式の検証一覧 | :white_check_mark: | :white_check_mark: |
| PDF / CSV 監査レポート | :x: | :white_check_mark: |
| 監査証跡レビュー用ツール(フラグ、レビュー担当者の承認) | :x: | :white_check_mark: |
| DE / FR / EN のレポートテンプレート | :x: | :white_check_mark: |
| 書き込みツールの変更前/変更後の値の取得 | :x: | :white_check_mark: |
| ツールの許可リスト/拒否リスト | :white_check_mark: | :white_check_mark: |
| HTTP メソッドとルートのポリシー | :white_check_mark: | :white_check_mark: |
| HTTPS リスナー(TLS 1.3、平文通信なし) | :white_check_mark: | :white_check_mark: |
| mTLS クライアント証明書による ID 確認 | :white_check_mark: | :white_check_mark: |
| プライベートファイルからの静的ベアラートークン(0600、または Windows の NTFS ACL) | :white_check_mark: | :white_check_mark: |
| リクエスト本文の SHA-256、任意で編集済みまたは全文を保存(全文の場合はレスポンステキストも保存) | :white_check_mark: | :white_check_mark: |
| MCP、HTTPS API、LLM API をまたぐゲートウェイフロー | :white_check_mark: | :white_check_mark: |
| HTTPS リスナー用 OIDC | :x: | :white_check_mark: |
| ローカルロール(operator、approver、qa、admin) | :white_check_mark: | :white_check_mark: |
| 書き込み前の人による承認 | :white_check_mark: | :white_check_mark: |
| Ed25519 / ECDSA 署名付きチェックポイント | :x: | :white_check_mark: |
| RFC 3161 タイムスタンプ | :x: | :white_check_mark: |
| IQ/OQ バリデーションパック | :x: | :white_check_mark: |
| SSO / OAuth | :x: | :white_check_mark: |
| Syslog(RFC 5424)/ SIEM エクスポート | :x: | :white_check_mark: |
| 鍵管理(KMS/HSM)、フィールドレベルの暗号化と編集 | :x: | :white_check_mark: |
| FIPS 140-3 モード | :x: | :x: 要問い合わせ |
| 包含/整合性証明に対応する Merkle ログ | :x: | :white_check_mark: |
| OpenTelemetry スパン(技術的なテレメトリーであり、監査記録ではありません) | :x: | :white_check_mark: |
| mcp-advanced-excel 向け GLP Lab Data Pack(来歴ハッシュ、機器テンプレート、高度な LOD/LOQ とモル単位、バッチ処理、Ed25519 署名付き出力) | :x: | :white_check_mark: |
| リモートアップストリームへの TLS 1.3 接続、トークンのパススルーなし | :white_check_mark: | :white_check_mark: |
| オフラインのライセンスファイル、ホームへの通信なし | :white_check_mark: | :white_check_mark: 同じファイルを読み込みます |
| 設定ウィザードと設定チェック | :white_check_mark: | :white_check_mark: |
2026-10-25 にこのリポジトリで確認済みです。コミュニティ版の機能はコードと一致しています。JSONL ストア、verify CLI、JSON およびテキストのレポーター、glp_search_audit / glp_export_audit、許可リストと拒否リスト、HTTP メソッドとルートのポリシー、4 つのローカルロール、approval として保存される glp_approve、署名なしのチェックポイント、tlsutil.py および HTTPS リスナーでの TLS 1.3、mTLS と静的ベアラーファイル、body_mode、オフラインライセンスローダー(LM1 および LM2)、init / config check です。HTTPS リスナー向けの OIDC はこのツリーにはありません。Pro の機能は docs/COVERAGE.md のエディション列に従っています。このツリー外のプラグインでは licence_feature が宣言されています。ライセンスのフィンガープリントがこのインストールの client_id およびライセンス対象プラグインと一致すると、コミュニティ版でその機能が有効になります。ライセンスの形式については「Configure」を参照してください。フィンガープリントはマシン ID ではありません。PostgreSQL、MSSQL、S3 Object Lock、PDF/CSV、Ed25519/ECDSA、RFC 3161、IQ/OQ パック、SSO/OAuth はこのツリーに実装されていません。個人の Part 11 電子署名は、どちらのエディションでも対象外です。Syslog、KMS/HSM、レビュー用フラグ/承認は docs/COVERAGE.md で Pro とされており、このツリーにはありません。DE/FR/EN テンプレート、Merkle ログ、旧値/新値の取得、OpenTelemetry スパンは Pro 向けとして記載されています。FIPS 140-3 モードは要望に応じて提供されます。オープンソースの OQ ランナー(mcp-glp-audit-proxy-oq)は IQ/OQ 検証パックではありません。 |
プラグインのエントリーポイント、AuditStore / Signer / Reporter の契約、ライセンスファイルについては docs/PLUGINS.md を参照してください。
ロードマップ
リリース済みのコミュニティ版の項目は、上記のセクションと CHANGELOG.md に記載されています。独立したロードマップファイルはありません。
ローカルツール
| ツール | 利用者 | 内容 |
|---|---|---|
glp_verify_chain | qa, approver, admin | チェーンの整合性を確認します。チェーンが破損している場合もレポートを返します。 |
glp_search_audit | qa, approver, admin | エントリーを絞り込みます。検索の監査記録にはフィルターと件数が保存され、各行のコピーは保存されません。 |
glp_export_audit | qa, approver, admin | ハッシュマニフェスト付きの JSON 電子エクスポートです。絞り込みエクスポートは complete: false としてマークされます。チェーンが破損している場合、エクスポートされません。 |
glp_approve | approver | approved、reviewed、または rejected の意味を記録します。 |
glp_update_policy | admin | 設定イベントを追記します。ポリシーはログから再生されます。 |
マニュアル
まずは docs/manual-guides/QUICKSTART.md にある、5 分でできるターミナル監査から始めてください。Claude Desktop、Claude Code、Cursor、VS Code、Windsurf、Cline、Continue、汎用 stdio クライアント、MCP Python SDK、LangChain、OpenAI Agents SDK、Docker、ラボ用 PC、共有ワークステーション、オフラインインストールのホスト設定は docs/manual-guides/ にあります。アップストリームの MCP サーバーには、このプロキシ経由でのみアクセスできるようにしてください。同じページで、アンカリング、承認、プラグインの選択、フェイルクローズのラッチについても説明しています。
安全性
SAFETY.md をお読みください。要点は、フェイルクローズ、トークンのパススルーなし、_meta からのシークレット除去、stdio の子プロセスに親の環境を引き継がせないこと、承認は電子署名ではないこと、JSONL ファイルは改ざんを検知できますが WORM ストアではないことです。
開発
pip install -e ".[dev]"
python -m pytest -q
OQ 形式のレポートランナーを実行するには、ソースのチェックアウト(tests/ と docs/verification/rtm.yaml)が必要です。PyPI からのインストールにはこのツリーは含まれません。同じランナーを呼び出すコマンド名が 2 つあります。どちらも非推奨ではありません。mcp-glp-audit-proxy-oq はインストールされるコンソールスクリプトで、mcp-glp-audit-proxy oq-report はモジュールのサブコマンドです。クローンから実行する場合:
mcp-glp-audit-proxy-oq --repo-root .
mcp-glp-audit-proxy oq-report --repo-root .
チェックアウトが見つからない場合、コマンドは終了コード 2 で終了し、pytest は開始されません。
CI では、Python 3.11、3.12、3.13 で同じテストスイートが実行されます(.github/workflows/ci.yml)。
MCP レジストリ
server.json では、公式 MCP レジストリ向けにこのサーバーを io.github.antonio-castellon/mcp-glp-audit-proxy として指定しています。このファイルの先頭行にあるマーカーがレジストリの検証対象です。
ライセンス
MIT。Copyright (c) 2026 Antonio Castellon / Castellon.CH。LICENSEを参照してください。
貢献方法についてはCONTRIBUTING.mdをご覧ください。行動規範はCODE_OF_CONDUCT.mdに記載されています。脆弱性の報告は公開 issue ではなく、SECURITY.mdに従って行ってください。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。