Ihr KI-Agent hat gestern 847 Tool-Aufrufe ausgeführt. Können Sie überprüfen, was er getan hat?
Manipulationssicheres Audit-Protokoll für KI-Agenten-Tool-Aufrufe.
Vorher:
{
"command": "npx",
"args": ["@modelcontextprotocol/server-github"]
}Nachher:
{
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
}Jeder Tool-Aufruf ist jetzt kryptografisch signiert und hash-verkettet. Sonst ändert sich nichts. Der MCP-Server funktioniert genau wie zuvor.
Related MCP server: Agent Audit Trail MCP Server
$ 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 e5f6a7b8Jeder Eintrag ist mit HMAC-SHA256 signiert und mit dem vorherigen Datensatz verkettet. Manipulieren Sie einen Eintrag, schlägt die Verifizierung fehl. Löschen Sie einen Eintrag, bricht die Kette.
$ 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.jsonlDer Befehl wrap startet Ihren MCP-Server als Kindprozess und sitzt zwischen Client und Server auf stdio. Er leitet ALLE Nachrichten transparent weiter. Nur tools/call-Antworten werden signiert und protokolliert. Alles andere passiert unverändert.
Beim ersten Start wird automatisch ein Signaturschlüssel in ~/.mcp-audit/key.hex erzeugt. Keine Konfiguration erforderlich.
{
"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..."
}Die attestation ist eine HMAC-SHA256-Signatur über die kanonischen Felder des Datensatzes. Der previousHash ist der SHA-256-Hash des vorherigen Datensatzes. Zusammen erkennen sie Manipulation, Reihenfolge und Vollständigkeit.
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 oder direkt in Ihrem MCP-Server-Befehl – mit mcp-audit wrap -- voranstellen.
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 pairFür Teams, die auch Zugriffskontrolle, Ratenbegrenzung und Multi-Server-Routing benötigen:
mcp-audit serve gateway.config.jsonDer vollständige Gateway fügt hinzu:
Policy-Engine (glob-basierte ACLs, Ratenbegrenzungen pro Prinzipal)
Tool-Namespacing über mehrere vorgelagerte MCP-Server
OpenTelemetry-Traces und Metrik-Export
Upstream-Health-Management mit automatischer Wiederverbindung
Ed25519-Signaturen (stärker als HMAC, portable Verifizierung)
Siehe Gateway-Konfiguration für das vollständige Schema.
npm install -g @mcp-audit-gateway/coreDies installiert die mcp-audit-CLI global. Oder ohne Installation verwenden:
npx @mcp-audit-gateway/core wrap -- <your mcp server command>Das Signatur- und Verifizierungssubsystem geht über das HMAC pro Datensatz hinaus. Es bietet Manipulationsnachweis über Log-Rotation, Crash-Recovery und Multi-Datei-Ketten hinweg.
Checkpoint-Datensätze ermöglichen es einem Konsumenten, Kürzungen am Ende zu erkennen, indem ein einzelner Hash extern gespeichert wird. Die Kette wird über Datei-Rotationen hinweg fortgeführt (keine stillen Neustarts). Erzwungene Neustarts erzeugen signierte chain_break-Datensätze, anstatt stillschweigend neu zu beginnen.
Die kanonische Form ist typmarkiert und injektiv, vermeidet JCS' Float-Formatierungsproblem, indem unsichere Zahlen vollständig abgelehnt werden, und hat nachweislich sprachübergreifende Parität über 46 Konformitätsvektoren (JS + Python). Siehe SECURITY-DESIGN.md für die vollständige Spezifikation und das Bedrohungsmodell.
MCP hat 10 offizielle SDKs und keine SDK-übergreifenden Konformitätstests. Wir haben einen Wycheproof-artigen Differenz-Harness gebaut, der 40 Serialisierungs-Grenzfälle über alle 10 SDKs ausführt und meldet, wo sie abweichen.
Ergebnisse: 26 Wire-Level-Abweichungen über 8 verschiedene Serialisierer. Sechs verschiedene Darstellungen von 1e20. Drei inkompatible Schlüssel-Sortieralgorithmen. TypeScript verliert stillschweigend Integer-Präzision bei 2^53+1. C# escaped Zeichen, die kein anderes SDK escaped. Das Python-SDK erzeugt unterschiedliche Bytes über pydantic-core-Versionen hinweg für denselben Codepfad.
./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 outputDie Kanonisierung des Audit-Gateways wurde entwickelt, um gegen alle 26 Abweichungsklassen immun zu sein: nur sichere Ganzzahlen, explizite Feldreihenfolge, Surrogat-Ablehnung. Siehe SDK-AUDIT.md für die vollständige Abweichungstabelle und Methodik.
Diese Implementierung erfüllt die folgenden Eigenschaften (verifiziert durch sprachübergreifende Konformitätsvektoren und Unit-Tests):
Injektive kanonische Form (keine kollidierenden Digests über Typen hinweg)
Sprachübergreifende Sortieräquivalenz (UTF-16-Code-Unit-Reihenfolge)
Ablehnung ungepaarter Surrogate
Kontinuität der Hash-Kette über Log-Rotation hinweg
Erkennung manipulierter Zustände beim Start
Keine Fehlalarme nach legitimer Kettenunterbrechung
Fail-closed bei beschädigter oder übermäßig großer Eingabe
Segmentierte Monotonie an chain_break-Grenzen
Vollständigkeit durch Verankerung beim Konsumenten über Checkpoint-Datensätze
Speicherbegrenzte Initialisierung (1-MB-Obergrenze)
APS action-ref-v1-Konformität: 51/51 Vektoren bestanden (JCS-Neuberechnung + Fail-closed-Digest-Vergleich).
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
Die APS-Konformitäts-Fixtures (test/vectors/aps-action-ref-v1-vectors.json)
sind aus Apache-2.0-Quellen von Drittanbietern übernommen. Siehe
test/vectors/SOURCE.md für Herkunft und Bedingungen.
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...
