通过模型上下文协议 (Model Context Protocol) 为 AI 智能体提供加密审计追踪
Related MCP server: DCL Evaluator
PiQrypt MCP 服务器为 PiQrypt 提供模型上下文协议 (Model Context Protocol) 访问权限——这是面向 AI 智能体的后量子密码审计追踪系统。
使用场景：
🤖 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 规范 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 任何诊断或分诊智能体都可以标记每项建议。提供符合 HIPAA 的审计追踪，将每个 AI 输出链接到可验证的智能体身份。
所有情况下的通用模式：
[Agent makes decision]
↓
piqrypt_stamp_event ← sign + chain
↓
[Agent executes action]
↓
piqrypt_export_audit ← portable proof, verifiable
without PiQrypt installedpiqrypt_stamp_event用加密证明签署 AI 决策。
参数：
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_events通过 SQLite 索引进行快速搜索。
参数：
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
});每个标记的事件都可以在 Vigil 中查看 — 这是 PiQrypt 的本地监控仪表板。
注意： Vigil 不会由 MCP 服务器自动启动。您必须在打开仪表板之前单独启动它。
piqrypt vigil
# → http://localhost:8421免费层级包括：链健康状况、VRS 风险评分、7 天历史记录、关键警报。升级到 Pro 可获得 90 天历史记录、TrustGate 治理和后量子签名。
智能体在首次标记时自动创建。要查看和删除智能体：
启动 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 piqrypt如果 piqrypt 安装在虚拟环境中而不是系统 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
由 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.