당신의 AI 에이전트가 어제 847번의 도구 호출을 했습니다. 그 내용을 검증할 수 있나요?
AI 에이전트 도구 호출에 대한 변조 방지 감사 추적.
이전:
{
"command": "npx",
"args": ["@modelcontextprotocol/server-github"]
}이후:
{
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
}모든 도구 호출은 이제 암호화 서명과 해시 체인으로 보호됩니다. 다른 것은 변경되지 않습니다. MCP 서버는 이전과 똑같이 작동합니다.
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 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.jsonlwrap 명령은 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전체 게이트웨이는 다음을 추가합니다:
정책 엔진 (glob 기반 ACL, 주체별 속도 제한)
여러 업스트림 MCP 서버에 걸친 도구 네임스페이싱
OpenTelemetry 추적 및 메트릭 내보내기
자동 재연결을 포함한 업스트림 상태 관리
Ed25519 서명 (HMAC보다 강력하고 휴대 가능한 검증)
전체 스키마는 게이트웨이 구성을 참조하세요.
npm install -g @mcp-audit-gateway/core이 명령은 mcp-audit CLI를 전역으로 설치합니다. 또는 설치 없이 사용:
npx @mcp-audit-gateway/core wrap -- <your mcp server command>서명 및 검증 하위 시스템은 레코드별 HMAC를 넘어섭니다. 로그 회전, 충돌 복구, 다중 파일 체인에서 변조 증거를 제공합니다.
체크포인트 레코드를 사용하면 소비자가 단일 해시를 외부에 저장하여 꼬리 잘림을 감지할 수 있습니다. 체인은 파일 회전을 넘어 계속됩니다 (조용한 재설정 없음). 강제 재시작은 조용히 새로 시작하는 대신 서명된 chain_break 레코드를 생성합니다.
정규 형식은 타입 태그가 지정되고 단사적이며, 안전하지 않은 숫자를 완전히 거부하여 JCS의 부동소수점 형식 문제를 피하고, 46개의 적합성 벡터(JS + Python)를 통해 교차 언어 동등성을 입증했습니다. 전체 사양과 위협 모델은 SECURITY-DESIGN.md를 참조하세요.
MCP에는 10개의 공식 SDK가 있지만 교차 SDK 적합성 테스트는 없습니다. 우리는 10개 SDK 모두에서 40개의 직렬화 엣지 케이스 테스트를 실행하고 불일치를 보고하는 Wycheproof 스타일의 차등 하네스를 구축했습니다.
결과: 8개의 서로 다른 직렬화기에서 26개의 와이어 수준 차이. 1e20의 6가지 다른 표현. 3개의 호환되지 않는 키 정렬 알고리즘. TypeScript는 2^53+1에서 정수 정밀도를 조용히 잃습니다. C#은 다른 SDK가 이스케이프하지 않는 문자를 HTML 이스케이프합니다. 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 경계에서의 세그먼트 단조성
체크포인트 레코드를 통한 소비자 앵커 완전성
메모리 제한 초기화 (1MB 상한)
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...
