Pista de auditoría criptográfica para agentes de IA mediante el Protocolo de Contexto de Modelo (MCP)
Related MCP server: DCL Evaluator
El servidor MCP de PiQrypt proporciona acceso mediante el Protocolo de Contexto de Modelo a PiQrypt, la pista de auditoría criptográfica post-cuántica para agentes de IA.
Casos de uso:
🤖 Agentes de IA: Firman cada decisión con una prueba criptográfica
📊 Flujos de trabajo en n8n: Añaden una pista de auditoría a los flujos de automatización
🏦 Bots de trading: Cumplimiento con SEC/FINRA para trading automatizado
👥 Automatización de RR. HH.: Decisiones de contratación por IA que cumplen con el RGPD
🏥 IA en salud: Pista de auditoría HIPAA para decisiones médicas
1. Instalar piqrypt (obligatorio — Python 3.8+)
pip install piqryptEl servidor MCP delega todas las operaciones criptográficas al paquete de Python piqrypt.
Si no está instalado, el servidor devolverá un error claro en cada llamada a la herramienta.
2. Instalar el servidor 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 buildPor defecto, el servidor utiliza python3 (Linux/Mac) o python (Windows).
Si piqrypt está instalado en un entorno virtual, establece esta variable para apuntar al intérprete correcto:
Windows
set PIQRYPT_PYTHON=C:\path\to\venv\Scripts\python.exeLinux / Mac
export PIQRYPT_PYTHON=/path/to/venv/bin/pythonPara hacerlo persistente, añádelo a la configuración de tu cliente MCP:
{
"mcpServers": {
"piqrypt": {
"command": "piqrypt-mcp-server",
"args": [],
"env": {
"PIQRYPT_PYTHON": "/path/to/venv/bin/python"
}
}
}
}Añadir a ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"piqrypt": {
"command": "piqrypt-mcp-server",
"args": []
}
}
}Instalar la integración MCP de n8n
Añadir el servidor MCP de PiQrypt a la configuración
Usar en flujos de trabajo mediante el nodo MCP
Cliente | Versión | Notas |
Cualquier cliente compatible con MCP | Especificación MCP 2024-11+ | transporte stdio |
n8n | 1.88+ | mediante nodo MCP |
Cursor | cualquiera | añadir a la configuración mcp |
VS Code | cualquiera | añadir a la configuración mcp |
Continue | cualquiera | añadir a la configuración mcp |
Windsurf | cualquiera | añadir a la configuración mcp |
Plataforma | Integración | Caso de uso |
n8n | Nodo MCP (nativo) | Pista de auditoría sin código |
Make.com | Módulo HTTP | Sellado activado por webhook |
Zapier | Webhooks + HTTP | Registro básico de eventos |
Cada llamada a la herramienta pasa por las mismas 4 operaciones: sellar, verificar, exportar, buscar. Esto es lo que significa en la práctica dependiendo de tu contexto:
Trading automatizado / finanzas Cualquier agente que envíe órdenes, reequilibre carteras o active transacciones puede sellar cada decisión antes de su ejecución. La cadena firmada es exportable para auditorías SEC/FINRA sin infraestructura adicional.
Automatización de RR. HH. y contratación Cualquier flujo de trabajo que evalúe candidatos, puntúe CVs o clasifique solicitantes puede sellar cada decisión. Proporciona una pista de auditoría conforme al Art. 22 del RGPD para la contratación asistida por IA: quién decidió qué, cuándo y qué datos se utilizaron (hash, nunca almacenados en bruto).
Canalizaciones de contenido y publicación Cualquier agente que redacte, apruebe o publique contenido puede sellar cada paso. Útil cuando varios agentes de IA colaboran y necesitas probar la atribución: qué agente escribió qué, y en qué orden.
DevOps y CI/CD Cualquier agente que active despliegues, fusione ramas o rote secretos puede sellar cada acción. Proporciona un registro a prueba de manipulaciones de los cambios de infraestructura realizados por agentes autónomos.
Salud e IA médica Cualquier agente de diagnóstico o triaje puede sellar cada recomendación. Proporciona una pista de auditoría conforme a HIPAA que vincula cada resultado de la IA con una identidad de agente verificable.
El patrón común en todos los casos:
[Agent makes decision]
↓
piqrypt_stamp_event ← sign + chain
↓
[Agent executes action]
↓
piqrypt_export_audit ← portable proof, verifiable
without PiQrypt installedpiqrypt_stamp_eventFirma una decisión de IA con una prueba criptográfica.
Parámetros:
agent_id (cadena, obligatorio): Identificador del agente
payload (objeto, obligatorio): Datos de la decisión
previous_hash (cadena, opcional): Hash del evento anterior para encadenar
Ejemplo:
const event = await mcp.call('piqrypt_stamp_event', {
agent_id: 'trading_bot_v1',
payload: {
action: 'buy',
symbol: 'AAPL',
quantity: 100,
price: 150.25
}
});Devuelve:
{
"version": "AISS-1.0",
"agent_id": "trading_bot_v1",
"timestamp": 1739382400,
"nonce": "uuid-...",
"payload": { ... },
"previous_hash": "sha256:...",
"signature": "base64:..."
}piqrypt_verify_chainVerifica la integridad de la cadena de eventos.
Parámetros:
events (matriz, obligatorio): Eventos a verificar
Ejemplo:
const result = await mcp.call('piqrypt_verify_chain', {
events: [event1, event2, event3]
});Devuelve:
{
"valid": true,
"events_count": 3,
"chain_hash": "sha256:...",
"errors": []
}piqrypt_export_auditExporta la pista de auditoría para cumplimiento normativo.
Parámetros:
agent_id (cadena, obligatorio): Agente a exportar
certified (booleano): Solicitar certificación de PiQrypt
output_format (cadena): json o pqz
Ejemplo:
const audit = await mcp.call('piqrypt_export_audit', {
agent_id: 'trading_bot_v1',
certified: true,
output_format: 'json'
});piqrypt_search_eventsBúsqueda rápida mediante índice SQLite.
Parámetros:
event_type (cadena, opcional): Filtrar por tipo
from_timestamp (número, opcional): Hora de inicio
to_timestamp (número, opcional): Hora de finalización
limit (número): Resultados máximos (por defecto: 100)
Ejemplo:
const trades = await mcp.call('piqrypt_search_events', {
event_type: 'trade_executed',
from_timestamp: 1739300000,
limit: 50
});Cada evento sellado es visible en Vigil: el panel de control de monitorización local de PiQrypt.
Nota: Vigil no se inicia automáticamente con el servidor MCP. Debes iniciarlo por separado antes de abrir el panel de control.
piqrypt vigil
# → http://localhost:8421El nivel gratuito incluye: salud de la cadena, puntuación de riesgo VRS, historial de 7 días, alertas CRÍTICAS. Actualiza a Pro para obtener historial de 90 días, gobernanza TrustGate y firmas post-cuánticas.
Los agentes se crean automáticamente en el primer sello. Para ver y eliminar agentes:
Inicia Vigil: piqrypt vigil
Ve a la vista All Agents
Selecciona los agentes a eliminar → haz clic en ✕ Delete selected
Confirma: Vigil vuelve a la pantalla de bienvenida cuando no quedan agentes
Los agentes se almacenan en
~/.piqrypt/agents/en tu máquina. Eliminar un agente elimina sus claves y su historial de eventos permanentemente.
┌─────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────┘✅ Las claves privadas nunca se exponen a la capa MCP ✅ Toda la criptografía en Python (Ed25519, Dilithium3) ✅ Misma seguridad que la CLI (aislamiento de procesos) ✅ Conforme a RFC AISS-1.1 (salida idéntica) ✅ Validación de entrada antes de la llamada al subproceso
[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 environmentEl intérprete de Python utilizado por el servidor MCP no puede encontrar el paquete piqrypt.
Solución:
pip install piqryptSi piqrypt está instalado en un entorno virtual y no en el Python del sistema, establece PIQRYPT_PYTHON para que apunte al intérprete correcto:
# Linux / Mac
export PIQRYPT_PYTHON=/path/to/venv/bin/python
# Windows
set PIQRYPT_PYTHON=C:\path\to\venv\Scripts\python.exePara verificar qué Python utilizará el servidor:
# Linux / Mac
$PIQRYPT_PYTHON -c "import aiss; print('ok')"
# Windows
%PIQRYPT_PYTHON% -c "import aiss; print('ok')"¡Agradecemos las contribuciones! Consulta CONTRIBUTING.md.
Servidor MCP → Licencia MIT - ver LICENSE Núcleo de PiQrypt → nivel gratuito + niveles comerciales
Núcleo de PiQrypt: https://github.com/piqrypt/piqrypt
Protocolo MCP: https://modelcontextprotocol.io
n8n: https://n8n.io
Documentación: https://docs.piqrypt.com
Creado con ❤️ por 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.