본문으로 건너뛰기
cccskills
무료GitHub에 공개

signed-audit-trails-recipe

Learn how to check Claude Code tool calls against a policy and create digitally signed execution records. This walkthrough covers setup, offline verification, tamper demonstrations, and CI/CD integration before adopting the protect-mcp runtime plugin.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Step-by-step cookbook for setting up cryptographically signed audit trails on Claude Code tool calls. Use when explaining, evaluating, or demonstrating the pattern before committing to the protect-mcp runtime hooks. Covers Cedar policy, Ed25519 receipts, offline verification, tamper detection, CI/CD integration, and SLSA composition.

설치 방법 보기

이럴 때 유용합니다

  • Evaluate signed audit records before adopting runtime hooks
  • Demonstrate offline verification and tamper detection
  • Verify agent execution records in CI/CD
  • Link agent execution records to SLSA provenance

포함된 파일(5)

  • SKILL.md9.9 KB
  • references/cedar-policy.md3.9 KB
  • references/ci-cd.md2.1 KB
  • references/hook-wiring.md1.3 KB
  • references/receipt-format.md1.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Signed Audit Trails for Claude Code Tool Calls

Cookbook-style walkthrough for cryptographically signed receipts on every Claude Code tool call. This is the teaching skill. For the runtime implementation, install the protect-mcp plugin.

What this gives you

Every tool call (Bash, Edit, Write, WebFetch) is:

  1. Evaluated against a Cedar policy before execution. If the policy denies the call, the tool does not run.
  2. Signed as an Ed25519 receipt after execution. Receipts are JCS-canonical and verifiable offline by anyone with the public key.

An auditor, regulator, or counterparty can verify every receipt later (Step 5). No network call, no vendor lookup, no trust in the operator.

When to use the pattern

  • Regulated environments (finance, healthcare, critical infrastructure) where you need tamper-evident evidence of agent behavior
  • CI/CD pipelines where you want to prove that a policy gate held for every automated build step
  • Multi-party collaboration where a counterparty wants to verify your agent's behavior without trusting your operator
  • Compliance contexts (EU AI Act Article 12, SLSA provenance for agent-built software) where standard logging is not sufficient

Step 1: Install the hook configuration

Install the protect-mcp plugin with /plugin install protect-mcp. Its hooks run evaluate.sh before each tool call and sign.sh after it. Both scripts read the hook event from stdin, because Claude Code sets no TOOL_NAME or TOOL_INPUT variables. See references/hook-wiring.md for the hook configuration and what each script passes to protect-mcp.

protect-mcp 0.7.4 does not create the signing key, and without a key the receipts are unsigned. Create ./protect-mcp.key once. The command never replaces an existing key:

if [ ! -e ./protect-mcp.key ]; then
  d=$(mktemp -d) && npx protect-mcp@0.7.4 init --dir "$d" && mv "$d/keys/gateway.json" ./protect-mcp.key
fi

Give auditors the publicKey value from that file. Do not commit the file, because it also holds the private key.

Add the private key and receipt directory to .gitignore:

echo "/protect-mcp.key" >> .gitignore
echo "/receipts/" >> .gitignore

Step 2: Write a Cedar policy

Create ./protect.cedar from the example in references/cedar-policy.md. It allows read-only tools and a short list of Bash commands, denies shell chaining and destructive commands, and limits writes to the project with .. segments denied.

Step 3: Use Claude Code normally

Start Claude Code. Every tool call goes through both hooks:

You: Please read the README and summarize it.

Claude: I will read README.md.
  [PreToolUse: Read ./README.md -> allow]
  [Tool: Read executes]
  [PostToolUse: receipt rcpt-a8f3c9d2 signed to ./receipts/]

... summary of README ...

A session of 20 tool calls appends 20 receipts to ./receipts/receipts.jsonl.

Step 4: Inspect a receipt

protect-mcp 0.7.4 appends each receipt as one line of ./receipts/receipts.jsonl. Print the newest one:

tail -n 1 ./receipts/receipts.jsonl | python3 -m json.tool

The receipt is a signed v2 envelope that names the tool, and it holds no public key. See references/receipt-format.md for a sample and the signed fields.

Step 5: Verify the receipts

Pass the publicKey value from ./protect-mcp.key to the verifier:

PUB=$(node -p 'JSON.parse(require("fs").readFileSync("./protect-mcp.key")).publicKey')
npx @veritasacta/verify@0.9.2 --replay-chain ./receipts/receipts.jsonl --key "$PUB"

Exit codes:

CodeMeaning
0Every receipt verified
1A receipt failed verification (tampered, wrong key, or malformed line)
2The receipts file could not be read

Step 6: Demonstrate tamper detection

Change the newest receipt's decision from allow to deny:

python3 -c "
import json
path = './receipts/receipts.jsonl'
lines = open(path).read().splitlines()
r = json.loads(lines[-1])
r['payload']['decision'] = 'deny'
lines[-1] = json.dumps(r)
open(path, 'w').write('\n'.join(lines) + '\n')
"

npx @veritasacta/verify@0.9.2 --replay-chain ./receipts/receipts.jsonl --key "$PUB"

The verifier exits with code 1 and reports which line failed. The Ed25519 signature no longer matches the JCS-canonical bytes of the tampered payload.

Restore the field and verification passes again.

How the cryptography works

Two invariants make receipts verifiable offline across any conformant implementation:

  1. JCS canonicalization (RFC 8785) before signing. Keys sorted by UTF-16 code units, whitespace minimized, strings not normalized. Two independent implementations produce byte-identical signing payloads for the same receipt content.
  2. Ed25519 signatures (RFC 8032) over the canonical bytes. Deterministic, fixed-size, no nonce dependency.

protect-mcp 0.7.4 receipts carry no link to the previous receipt, so a deleted receipt goes undetected.

For the formal wire format see draft-farley-acta-signed-receipts.

Cross-implementation interop

The receipt format has four independent implementations today:

ImplementationLanguageUse case
protect-mcpTypeScriptClaude Code, Cursor, MCP hosts
protect-mcp-adkPythonGoogle Agent Development Kit
sb-runtimeRustOS-level sandbox (Landlock + seccomp)
APS governance hookPythonCrewAI, LangChain

A receipt produced by any of them verifies against @veritasacta/verify. The auditor does not need to trust the operator's tooling choice: the format is the contract.

CI/CD integration

Verify receipts in CI so a tampered receipt fails the build. references/ci-cd.md has a GitHub Actions workflow that runs on pushes to the default branch. It installs the signing key from a branch-limited environment, runs the agent, verifies the receipts, and uploads them. It does not run on pull requests, because that would hand the key to unreviewed code.

Composition with SLSA provenance for agent-built software

When Claude Code builds and releases software (running npm install, npm build, npm publish as tool calls), the receipt chain is the per-step build log. SLSA Provenance v1 has an extension point for this: the byproducts field can reference the receipt chain alongside the build attestation.

The agent-commit build type documents the pattern using the ResourceDescriptor shape:

{
  "name": "decision-receipts",
  "digest": { "sha256": "..." },
  "uri": "oci://registry/org/build-xyz/receipts:sha256-...",
  "annotations": {
    "predicateType": "https://veritasacta.com/attestation/decision-receipt/v0.1",
    "signerRole": "supervisor-hook"
  }
}

The SLSA provenance is signed by the builder identity; the receipt attestation is signed by the supervisor-hook identity. Two trust domains, cross-referenced at the byproduct layer. See slsa-framework/slsa#1594 for the composition discussion.

Common pitfalls

Private key in version control. The generated ./protect-mcp.key must not be committed. The examples above add it to .gitignore. If a key is accidentally committed, rotate it immediately. Move the key and ./receipts/receipts.jsonl to an archive, then run the Step 1 command again. Verify the archived receipts with the old public key.

Hook payload on stdin. Claude Code sets no $TOOL_NAME or $TOOL_INPUT variables. A hook command that passes --tool "$TOOL_NAME" sends an empty tool name, so the policy denies every call. Read the payload from stdin as the plugin scripts do.

Receipts directory in CI. If Claude Code runs in CI, upload receipts as an artifact at the end of the job or the receipts are lost at job end.

Policy is missing. When ./protect.cedar does not exist, evaluate.sh prints a warning to stderr and allows the call. No call is gated until you create the policy in Step 2.

Related in this marketplace

  • protect-mcp — the runtime hook implementation (use this plugin in production)
  • review-agent-governance — require human approval before review-surface actions; composes with protect-mcp

References

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Build and review interfaces against WCAG 2.2 accessibility guidelines. Covers keyboard navigation, screen readers that read interface content aloud, accessible forms, mobile support, and display preferences, helping identify and fix barriers to using a website or app.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Audit an interface for accessibility issues
  • Add keyboard navigation and focus management
  • Improve screen reader support for forms
wshobson/agents4.1만2026년 10월 19일 업데이트

Review AI-generated code for problems hidden behind successful runs. Check failure handling, resource cleanup, unusual inputs, nonexistent dependencies, and departures from project conventions to identify missing safeguards before merging or accepting the work as complete.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Audit code after an AI generation session
  • Review an AI-generated pull request before merging
  • Investigate brittle code that appears to work
wshobson/agents4.1만2026년 10월 19일 업데이트

Build Apache Airflow workflows for data pipelines and scheduled jobs. The skill guides task dependencies, retries, waiting for conditions, testing, and deployment, with patterns for tasks that can be safely rerun.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Building scheduled data pipelines
  • Designing task order and dependencies
  • Implementing custom tasks and condition checks
wshobson/agents4.1만2026년 10월 19일 업데이트

Plan and carry out an AngularJS to Angular migration, from choosing a rewrite strategy to converting components, services, and routes. Includes a hybrid approach that runs both frameworks together while individual features are migrated.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Planning an AngularJS to Angular migration
  • Moving a large app one feature at a time
  • Converting directives into Angular components
wshobson/agents4.1만2026년 10월 19일 업데이트

Identify software protections that hinder inspection, such as debugger detection and obfuscation that makes code harder to understand. Support authorized binary analysis and CTF security challenges with protection findings, bypass strategies, reports, and analysis scripts.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Identify protections in an authorized malware sample
  • Plan analysis of a packed executable
  • Implement debugger detection for a CTF challenge
wshobson/agents4.1만2026년 10월 19일 업데이트

Design and review REST and GraphQL APIs with consistent naming, data structures, error responses, pagination for large result sets, and versioning strategies. Helps teams define shared standards and plan changes that existing clients can adopt gradually.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Designing a new REST or GraphQL API
  • Reviewing API specifications before implementation
  • Establishing shared API design standards
wshobson/agents4.1만2026년 10월 19일 업데이트

wshobson의 스킬 모두 보기

이 스킬의 문제 신고