Model Context Protocolを介したAIエージェントのための暗号学的監査証跡
Related MCP server: DCL Evaluator
PiQrypt MCPサーバーは、AIエージェントのための耐量子暗号監査証跡であるPiQryptへのModel Context Protocolアクセスを提供します。
ユースケース:
🤖 AIエージェント: すべての意思決定に暗号学的証明で署名
📊 n8nワークフロー: 自動化ワークフローに監査証跡を追加
🏦 トレーディングボット: 自動取引のためのSEC/FINRAコンプライアンス
👥 人事自動化: GDPR準拠のAI採用決定
🏥 ヘルスケアAI: 医療判断のためのHIPAA監査証跡
1. piqryptのインストール（必須 — Python 3.8以上）
pip install piqryptMCPサーバーは、すべての暗号操作をpiqrypt Pythonパッケージに委任します。
インストールされていない場合、サーバーはツール呼び出しのたびに明確なエラーを返します。
2. MCPサーバーのインストール（Node.js 18以上）
npm install -g @piqrypt/mcp-servernpx @piqrypt/mcp-servergit clone https://github.com/piqrypt/piqrypt-mcp-server
cd piqrypt-mcp-server
npm install
npm run buildデフォルトでは、サーバーはpython3（Linux/Mac）またはpython（Windows）を使用します。
piqryptが仮想環境にインストールされている場合は、この変数を適切なインタープリタを指すように設定してください：
Windows
set PIQRYPT_PYTHON=C:\path\to\venv\Scripts\python.exeLinux / Mac
export PIQRYPT_PYTHON=/path/to/venv/bin/python永続化するには、MCPクライアント設定に追加してください：
{
"mcpServers": {
"piqrypt": {
"command": "piqrypt-mcp-server",
"args": [],
"env": {
"PIQRYPT_PYTHON": "/path/to/venv/bin/python"
}
}
}
}~/Library/Application Support/Claude/claude_desktop_config.jsonに追加します：
{
"mcpServers": {
"piqrypt": {
"command": "piqrypt-mcp-server",
"args": []
}
}
}n8n MCP統合をインストール
PiQrypt MCPサーバーを設定に追加
MCPノード経由でワークフローで使用
クライアント | バージョン | 備考 |
MCP互換クライアント | MCP spec 2024-11+ | stdioトランスポート |
n8n | 1.88+ | MCPノード経由 |
Cursor | すべて | mcp設定に追加 |
VS Code | すべて | mcp設定に追加 |
Continue | すべて | mcp設定に追加 |
Windsurf | すべて | mcp設定に追加 |
プラットフォーム | 統合 | ユースケース |
n8n | MCPノード (ネイティブ) | ノーコード監査証跡 |
Make.com | HTTPモジュール | Webhookトリガーによるスタンプ |
Zapier | Webhooks + HTTP | 基本的なイベント記録 |
すべてのツール呼び出しは、スタンプ、検証、エクスポート、検索という同じ4つの操作を経由します。コンテキストに応じて、実際には以下のような意味を持ちます：
自動取引 / 金融 注文の送信、ポートフォリオのリバランス、取引のトリガーを行うエージェントは、実行前に各意思決定をスタンプできます。署名されたチェーンは、追加のインフラなしでSEC/FINRA監査用にエクスポート可能です。
人事および採用の自動化 候補者の評価、履歴書のスコアリング、応募者のルーティングを行うワークフローは、各意思決定をスタンプできます。AI支援による採用のためのGDPR第22条準拠の監査証跡を提供します。誰が何をいつ決定し、どのようなデータが使用されたか（ハッシュ化され、生データは保存されません）を記録します。
コンテンツおよび出版パイプライン コンテンツの草案作成、承認、公開を行うエージェントは、各ステップをスタンプできます。複数のAIエージェントが協力し、帰属関係を証明する必要がある場合に便利です。どのエージェントがどの順序で何を書いたかを証明できます。
DevOpsおよびCI/CD デプロイのトリガー、ブランチのマージ、シークレットのローテーションを行うエージェントは、各アクションをスタンプできます。自律型エージェントによって行われたインフラ変更の改ざん防止記録を提供します。
ヘルスケアおよび医療AI 診断やトリアージを行うエージェントは、各推奨事項をスタンプできます。各AI出力を検証可能なエージェントIDにリンクするHIPAA準拠の監査証跡を提供します。
すべてのケースにおける共通パターン:
[Agent makes decision]
↓
piqrypt_stamp_event ← sign + chain
↓
[Agent executes action]
↓
piqrypt_export_audit ← portable proof, verifiable
without PiQrypt installedpiqrypt_stamp_eventAIの意思決定に暗号学的証明で署名します。
パラメータ:
agent_id (文字列, 必須): エージェント識別子
payload (オブジェクト, 必須): 意思決定データ
previous_hash (文字列, オプション): チェーンのための前のイベントハッシュ
例:
const event = await mcp.call('piqrypt_stamp_event', {
agent_id: 'trading_bot_v1',
payload: {
action: 'buy',
symbol: 'AAPL',
quantity: 100,
price: 150.25
}
});戻り値:
{
"version": "AISS-1.0",
"agent_id": "trading_bot_v1",
"timestamp": 1739382400,
"nonce": "uuid-...",
"payload": { ... },
"previous_hash": "sha256:...",
"signature": "base64:..."
}piqrypt_verify_chainイベントチェーンの整合性を検証します。
パラメータ:
events (配列, 必須): 検証するイベント
例:
const result = await mcp.call('piqrypt_verify_chain', {
events: [event1, event2, event3]
});戻り値:
{
"valid": true,
"events_count": 3,
"chain_hash": "sha256:...",
"errors": []
}piqrypt_export_auditコンプライアンスのために監査証跡をエクスポートします。
パラメータ:
agent_id (文字列, 必須): エクスポートするエージェント
certified (ブール値): PiQrypt認証を要求
output_format (文字列): json または pqz
例:
const audit = await mcp.call('piqrypt_export_audit', {
agent_id: 'trading_bot_v1',
certified: true,
output_format: 'json'
});piqrypt_search_eventsSQLiteインデックスによる高速検索。
パラメータ:
event_type (文字列, オプション): タイプでフィルタリング
from_timestamp (数値, オプション): 開始時間
to_timestamp (数値, オプション): 終了時間
limit (数値): 最大結果数 (デフォルト: 100)
例:
const trades = await mcp.call('piqrypt_search_events', {
event_type: 'trade_executed',
from_timestamp: 1739300000,
limit: 50
});スタンプされたすべてのイベントは、PiQryptのローカル監視ダッシュボードであるVigilで確認できます。
注: VigilはMCPサーバーによって自動的に起動されません。 ダッシュボードを開く前に、個別に起動する必要があります。
piqrypt vigil
# → http://localhost:8421無料プランには、チェーンの健全性、VRSリスクスコア、7日間の履歴、重大なアラートが含まれます。 90日間の履歴、TrustGateガバナンス、耐量子署名についてはProにアップグレードしてください。
エージェントは最初のスタンプ時に自動的に作成されます。エージェントを表示および削除するには：
Vigilを起動: piqrypt vigil
All Agents ビューに移動
削除するエージェントにチェックを入れる → ✕ Delete selected をクリック
確認 — エージェントが残っていない場合、Vigilはウェルカム画面に戻ります
エージェントはマシン上の
~/.piqrypt/agents/に保存されます。 エージェントを削除すると、そのキーとイベント履歴が完全に削除されます。
┌─────────────────────────────────────┐
│ MCP Client (any MCP-compatible client) │
│ ↓ JSON-RPC over stdio │
├─────────────────────────────────────┤
│ MCP Server (TypeScript/Node.js) │ ← No crypto here
│ ↓ subprocess call │
├─────────────────────────────────────┤
│ Python Bridge (bridge.py) │
│ ↓ invokes CLI │
├─────────────────────────────────────┤
│ PiQrypt CLI (Python) │
│ ↓ uses │
├─────────────────────────────────────┤
│ Core Crypto (aiss package) │ ← All crypto here
│ • Ed25519 / Dilithium3 │
│ • RFC 8785 canonical JSON │
│ • Hash chains │
└─────────────────────────────────────┘✅ 秘密鍵はMCP層に決して公開されません ✅ すべての暗号処理はPython内で行われます (Ed25519, Dilithium3) ✅ CLIと同じセキュリティ (プロセス分離) ✅ RFC AISS-1.1準拠 (同一の出力) ✅ サブプロセス呼び出し前の入力検証
[Webhook: price alert]
↓
[AI Decision: buy/sell?]
↓
[PiQrypt MCP: stamp decision] ← Audit trail
↓
[Execute trade API]
↓
[Database: store proof][Upload CV]
↓
[AI Agent: evaluate candidate]
↓
[PiQrypt MCP: stamp evaluation] ← GDPR compliance
↓
[Email HR team]# Build
npm run build
# Test bridge
python3 src/python/bridge.py stamp '{"agent_id":"test","payload":{"action":"test"}}'
# Test MCP server (manual)
node dist/index.js
# Then send MCP request via stdinError: piqrypt is not installed in this Python environmentMCPサーバーが使用しているPythonインタープリタがpiqryptパッケージを見つけられません。
修正:
pip install piqryptpiqryptがシステムPythonではなく仮想環境にインストールされている場合は、PIQRYPT_PYTHONを正しいインタープリタを指すように設定してください：
# Linux / Mac
export PIQRYPT_PYTHON=/path/to/venv/bin/python
# Windows
set PIQRYPT_PYTHON=C:\path\to\venv\Scripts\python.exeサーバーが使用するPythonを確認するには：
# Linux / Mac
$PIQRYPT_PYTHON -c "import aiss; print('ok')"
# Windows
%PIQRYPT_PYTHON% -c "import aiss; print('ok')"貢献を歓迎します！CONTRIBUTING.mdを参照してください。
MCPサーバー → MITライセンス - LICENSEを参照 PiQryptコア → 無料プラン + 商用プラン
PiQryptコア: https://github.com/piqrypt/piqrypt
MCPプロトコル: https://modelcontextprotocol.io
n8n: https://n8n.io
ドキュメント: https://docs.piqrypt.com
Built with ❤️ by PiQrypt Inc.
Export the complete agent audit trail to a portable JSON archive. Set certified=true to request a PiQrypt CA signature for legal admissibility (eIDAS Art.26). The export is self-contained and verifiable without PiQrypt installed.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent ID to export | |
| certified | No | Create certified export (requires Pro license) | |
| output_format | No | Output format (json or encrypted pqz archive) | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that export is self-contained and verifiable, and mentions Pro license requirement. Does not detail side effects or reading behavior; with no annotations, this is moderate.
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?
Two sentences, each adding essential information: purpose and certification detail. 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?
Lacks output schema but describes the result as a portable JSON archive. Missing details on error conditions or what the audit trail contains, but adequate for a simple export.
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 baseline is 3. Description adds value for the certified parameter (legal admissibility) and clarifies the export scope (complete trail).
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 tool exports a complete agent audit trail to JSON, using a specific verb and resource. It distinguishes well from sibling tools like piqrypt_search_events.
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?
Provides context on when to use certified=true and notes the export is self-contained. Lacks explicit when-not-to-use or alternatives, but siblings are distinct actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the agent's cryptographic event history by type, time range, or session. Returns signed events with chain metadata. Use to reconstruct what an agent did during a specific period.
| Name | Required | Description | Default |
|---|---|---|---|
| event_type | No | Filter by event type (e.g., "trade_executed", "decision_made") | |
| from_timestamp | No | Start timestamp (Unix UTC seconds) | |
| to_timestamp | No | End timestamp (Unix UTC seconds) | |
| limit | No | Maximum number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it returns signed events with chain metadata, implying read-only. However, it does not mention authentication, rate limits, pagination behavior, or what happens with empty results.
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?
Three concise sentences with no filler. The action verb is front-loaded, and every sentence adds useful context.
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 gives a brief idea of return values (signed events with chain metadata) but omits details like event structure or metadata fields. The mention of session without a corresponding parameter reduces completeness.
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 the description adds minimal value beyond repeating filter options. It mentions session but the schema lacks a session parameter, creating slight ambiguity.
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?
Clearly states verb (search), resource (cryptographic event history), and scope (by type, time range, or session). Distinguishes from siblings like piqrypt_stamp_event (create) and piqrypt_export_audit (export).
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?
Provides a clear use case ('reconstruct what an agent did during a specific period'), but does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a tamper-proof cryptographic record of an agent decision. Signs the event with Ed25519, links it to the previous event in a hash chain (AISS v2.0). Call this after every significant agent action. Required for GDPR Art.22, EU AI Act Art.13, HIPAA audit trail, SEC/FINRA trading compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g., "trading_bot_v1", "hr_decision_engine") | |
| payload | Yes | Event payload containing decision data (JSON object) | |
| previous_hash | No | Optional hash of previous event for chain integrity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: tamper-proof record creation, Ed25519 signing, and hash chain linking. It lacks details on side effects, idempotency, or error handling, but covers essential traits.
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 at two sentences, front-loading the purpose and including key details. It is efficient but could be slightly more structured by grouping regulations separately.
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 tool with 3 parameters and no output schema, the description covers purpose, usage, and behavioral details adequately. The lack of return value description is a minor shortfall, but overall it is fairly complete.
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?
The input schema already describes all three parameters with 100% coverage. The description adds no additional semantics beyond the schema, so a baseline score of 3 is appropriate.
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 tool creates a cryptographic record, specifying the signing algorithm (Ed25519) and chaining mechanism (AISS v2.0), which distinguishes it from sibling tools for export, search, and verification.
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?
The description explicitly advises 'Call this after every significant agent action' and lists regulatory requirements, providing strong contextual cues. However, it does not explicitly exclude cases where the tool should not be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that an agent's decision history is intact and untampered. Detects modified events, missing events, hash chain breaks, and forks. Call before trusting any historical agent output.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | Array of PiQrypt events to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately describes what the tool detects (tampering evidence). However, it lacks details on output/return behavior (e.g., error vs result) and side effects, which would improve transparency.
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?
Two sentences, no wasted words, front-loaded with the main action and key details.
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 tool with full schema coverage, the description covers purpose and usage. It lacks specification of return value (e.g., boolean, report), but overall is complete enough for an agent to invoke correctly.
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 description does not add additional meaning beyond the schema's 'Array of PiQrypt events to verify'. Baseline score of 3 is appropriate as the schema already carries the parameter semantics.
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 tool's purpose: verifying integrity of an agent's decision history. It lists specific detection capabilities (modified events, missing events, etc.) and distinguishes itself from siblings by its verification role.
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?
The description includes explicit usage guidance: 'Call before trusting any historical agent output.' While it doesn't explicitly exclude scenarios or name alternatives, the clear context is sufficient for an agent to decide when to invoke this tool.
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.
v1.5.3piqrypt_export_auditpiqrypt_search_eventspiqrypt_stamp_eventpiqrypt_verify_chainScored across 4 tools
Each tool maps to a distinct action in the audit workflow: stamping, exporting, searching, and verifying. The descriptions make the boundaries clear, and even the slight overlap between search and export is resolved by their different purposes.
Every tool follows the same snake_case convention with a shared 'piqrypt_' prefix and a clear verb_object pattern, such as stamp_event and verify_chain. The small singular/plural variation is natural and does not hurt predictability.
Four tools is well-scoped for a focused cryptographic audit-log server. Each tool covers a necessary part of the lifecycle and none feels redundant or missing.
The tool surface covers the full lifecycle of an append-only audit trail: create, query, export, and verify. Missing update/delete operations are appropriate for a tamper-proof audit system, so there are no obvious dead ends.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Register every AI agent, log every action, prove it. EU AI Act compliance built in.
Bitcoin-anchored, tamper-evident audit-permanence layer for AI agents, FRE 902(13)/(14)-shaped.