Ваш ИИ-агент вчера совершил 847 вызовов инструментов. Можете ли вы проверить, что он делал?
Защищённый от вмешательства журнал аудита для вызовов инструментов ИИ-агента.
До:
{
"command": "npx",
"args": ["@modelcontextprotocol/server-github"]
}После:
{
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
}Теперь каждый вызов инструмента криптографически подписан и связан хеш-цепочкой. Больше ничего не меняется. MCP-сервер работает точно так же, как и раньше.
Related MCP server: DCL Evaluator
$ mcp-audit tail
✓ 14:32:01 github/create_pr 234ms bf7a2f62
✓ 14:32:03 github/list_issues 89ms a1c4e890
✗ 14:32:05 fs/delete_file 12ms c3d9f012
✓ 14:32:08 github/merge_pr 456ms e5f6a7b8Каждая запись подписана с помощью HMAC-SHA256 и связана с предыдущей записью. Внесите изменения в любую запись — и проверка не пройдёт. Удалите запись — и цепочка разорвётся.
$ mcp-audit verify ~/.mcp-audit/audit.jsonl
Results:
Total records: 847
Valid: 847
Invalid: 0
All records verified successfully.┌────────────┐ ┌───────────┐ ┌────────────┐
│ MCP Client │──────▶│ mcp-audit │──────▶│ MCP Server │
│ (Claude, │◀──────│ wrap │◀──────│ (any) │
│ Cursor) │ └─────┬─────┘ └────────────┘
└────────────┘ │
▼
~/.mcp-audit/
audit.jsonlКоманда wrap запускает ваш MCP-сервер как дочерний процесс и располагается между клиентом и сервером на stdio. Она прозрачно пересылает ВСЕ сообщения. Только ответы tools/call подписываются и записываются в журнал. Всё остальное проходит без изменений.
При первом запуске ключ подписи автоматически генерируется в ~/.mcp-audit/key.hex. Никакой настройки не требуется.
{
"id": "bf7a2f62-4d0f-4cce-afd2-cbfbf7bca2a5",
"timestamp": "2026-08-16T14:32:01.000Z",
"method": "tools/call",
"toolName": "github/create_pr",
"args": {"title": "Fix bug", "body": "..."},
"durationMs": 234,
"success": true,
"previousHash": "8a3f2b...",
"attestation": "7c4d9e..."
}attestation — это подпись HMAC-SHA256 по каноническим полям записи. previousHash — это SHA-256 предыдущей записи. Вместе они обнаруживают вмешательство, нарушение порядка и неполноту.
claude_desktop_config.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
},
"filesystem": {
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-filesystem", "/tmp"]
}
}
}.claude/hooks/mcp-servers.json или напрямую в команде вашего MCP-сервера — добавьте префикс mcp-audit wrap --.
mcp-audit wrap -- <cmd> [args] # Wrap any MCP server
mcp-audit tail # Live stream of tool calls
mcp-audit verify <log> # Verify chain integrity
mcp-audit serve [config] # Full gateway (policy + OTel)
mcp-audit keygen [dir] # Generate Ed25519 key pairДля команд, которым также нужны контроль доступа, ограничение скорости и маршрутизация между несколькими серверами:
mcp-audit serve gateway.config.jsonПолный шлюз добавляет:
Политический движок (ACL на основе glob, ограничения скорости для каждого принципала)
Пространства имён инструментов для нескольких вышестоящих MCP-серверов
Экспорт трассировок и метрик OpenTelemetry
Управление работоспособностью вышестоящих серверов с автоматическим переподключением
Подписи Ed25519 (сильнее, чем HMAC, переносимая проверка)
См. конфигурацию шлюза для полной схемы.
npm install -g @mcp-audit-gateway/coreЭто устанавливает CLI mcp-audit глобально. Или используйте без установки:
npx @mcp-audit-gateway/core wrap -- <your mcp server command>Подсистема подписи и проверки выходит за рамки пофайлового HMAC. Она обеспечивает доказательство вмешательства при ротации журналов, восстановлении после сбоев и многофайловых цепочках.
Контрольные записи позволяют потребителю обнаружить усечение хвоста, сохраняя один хеш во внешнем хранилище. Цепочка продолжается при ротации файлов (без тихого сброса). Принудительные перезапуски создают подписанные записи chain_break вместо тихого начала с нуля.
Каноническая форма типизирована и инъективна, избегает проблемы форматирования чисел с плавающей запятой в JCS, полностью отвергая небезопасные числа, и доказала межъязыковую совместимость с помощью 46 конформационных векторов (JS + Python). См. SECURITY-DESIGN.md для полной спецификации и модели угроз.
MCP имеет 10 официальных SDK и не имеет меж-SDK конформационного тестирования. Мы создали дифференциальный стенд в стиле Wycheproof, который запускает 40 тестов на граничные случаи сериализации во всех 10 SDK и сообщает, где они расходятся.
Результаты: 26 расхождений на уровне проводов в 8 различных сериализаторах. Шесть различных представлений 1e20. Три несовместимых алгоритма упорядочивания ключей. TypeScript молча теряет точность целых чисел при 2^53+1. C# экранирует HTML-символы, которые не экранирует ни один другой SDK. Python SDK выдаёт разные байты в разных версиях pydantic-core для одного и того же пути кода.
./test/vectors/cross-sdk-diff.sh # full matrix (stdlib + SDK)
./test/vectors/cross-sdk-diff.sh --layer sdk # SDK-wire-level only
./test/vectors/cross-sdk-diff.sh --json # structured outputКанонизация аудиторского шлюза была разработана так, чтобы быть невосприимчивой ко всем 26 классам расхождений: только безопасные целые числа, явный порядок полей, отклонение суррогатов. См. SDK-AUDIT.md для полной таблицы расхождений и методологии.
Эта реализация удовлетворяет следующим свойствам (проверено межъязыковыми конформационными векторами и модульными тестами):
Инъективная каноническая форма (без коллизий дайджестов между типами)
Межъязыковая эквивалентность сортировки (порядок кодовых единиц UTF-16)
Отклонение непарных суррогатов
Непрерывность хеш-цепочки при ротации журналов
Обнаружение внедрённого состояния при запуске
Отсутствие ложных срабатываний после легитимного разрыва цепочки
Отказ при повреждённом или слишком большом входе
Сегментированная монотонность на границах chain_break
Полнота, закреплённая за потребителем, через контрольные записи
Инициализация с ограниченной памятью (лимит 1 МБ)
Соответствие APS action-ref-v1: 51/51 векторов пройдено (пересчёт JCS + сравнение дайджестов с отказом при ошибке).
npm test # unit tests
node test/vectors/verify-checkpoint.mjs # JS conformance vectors
python3 test/vectors/verify-checkpoint.py # Python conformance vectors
node test/vectors/aps-action-ref-v1.mjs # 51 APS vectors
./test/vectors/cross-sdk-diff.sh # 10-SDK differential testMIT
Фикстуры соответствия APS (test/vectors/aps-action-ref-v1-vectors.json)
адаптированы из исходников Apache-2.0. См.
test/vectors/SOURCE.md для сведений о происхождении и условиях.
Report current audit chain health: total records, last verified timestamp, chain integrity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully indicates the tool reports total records, last verified timestamp, and chain integrity, and 'Report' implies a read-only snapshot. However, it does not explicitly state side-effect-freedom, failure behavior, or what 'chain integrity' means operationally.
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 sentence that front-loads the action and resource, then concisely lists the three report contents. There is no redundant or wasted text.
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 parameterless status tool, the description is nearly complete: it names the purpose and the expected output fields. It lacks sibling-selection guidance, but the low complexity and zero-parameter signature make that a relatively small gap.
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 tool has zero parameters, so the baseline is 4. The description adds value by clarifying what the status report contains, which is the only semantic information needed for a parameterless tool.
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 states a specific verb and resource: 'Report current audit chain health.' It also enumerates the report contents, making the tool's purpose unambiguous. However, it does not explicitly distinguish this tool from the sibling tools audit_verify and audit_tail.
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 usage guidance is provided. The description does not mention when to use audit_status versus audit_verify or audit_tail, nor does it state any exclusions or prerequisites. Selection among siblings is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the most recent audit log entries with verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of entries to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Show' implies a non-destructive read operation, but the description does not explicitly state read-only behavior, permissions, or any other side effects or limitations. Minimal behavioral context is disclosed.
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?
A single sentence that front-loads the core action and resource with no filler or redundancy. Every word earns its place.
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 one optional parameter and no output schema, the description sufficiently communicates what is returned (recent audit log entries with verification status). It lacks sibling routing and caveats, but is functionally complete for the simple use case.
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 description coverage is 100% for the single 'count' parameter, which already includes its default value. The tool description itself adds no additional meaning about the parameter, so the baseline score of 3 applies.
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 uses a specific verb ('Show'), a clear resource ('audit log entries'), and a scope qualifier ('most recent'), while adding a distinctive output feature ('verification status'). This differentiates it from siblings like audit_verify and audit_status.
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 implies usage for viewing recent audit logs but provides no explicit guidance on when to use this tool over audit_verify or audit_status. There are no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify integrity of an MCP audit log. Returns chain status and any broken links.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | Yes | Path to the audit log file (JSONL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose that the tool returns chain status and broken links, which is valuable, but it does not mention whether the operation is read-only, if there are side effects, or how failures are reported.
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 two concise sentences with no filler. The core action is front-loaded, and the return behavior is stated immediately after, making it easy to scan.
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 single-parameter tool with no output schema, the description gives the essential purpose and return information. It is slightly incomplete on when to choose this over sibling tools, but the overall definition is sufficient for basic invocation.
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 description coverage is 100%, and the only parameter, logPath, is already described in the schema as 'Path to the audit log file (JSONL)'. The tool description adds no additional parameter-level detail, so the schema provides the necessary 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 uses a specific verb ('Verify integrity') with a clear resource ('MCP audit log') and states the outcome ('Returns chain status and any broken links'). It clearly distinguishes this from sibling tools like audit_tail and audit_status, which have different operational purposes.
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 is provided on when to use this tool versus audit_tail or audit_status. The description only states what the tool does, leaving the agent to infer the appropriate selection context without any exclusions or alternatives.
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.
audit_statusaudit_tailaudit_verifyThis server cannot be deployed
Scored across 3 tools
audit_tail is clearly distinct, showing recent entries. audit_verify and audit_status overlap somewhat in reporting integrity, but verify focuses on running a chain verification while status provides a summary snapshot.
All tools share the consistent audit_ prefix and lowercase single-word suffixes. The suffixes mix a verb (verify), a command-style word (tail), and a noun (status), but the pattern remains predictable.
Three tools is well-scoped for an audit gateway surface. Each tool covers a distinct aspect of interacting with the audit log without unnecessary bloat.
The set covers the core audit operations: verifying integrity, tailing recent entries, and reporting chain health. It lacks operations like fetching a single entry or exporting records, but those are reasonable minor gaps.
Signed, publicly logged records of what your AI agent did, with proofs anyone can check offline.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Signed, append-only receipts of an AI agent's decisions and outcomes, with public proof links.
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...