How to use the protect-mcp Setup agent skill for Claude Code

What is an agent skill, and what does this one do?

An agent skill is a folder of instructions that Claude can load when a task matches the skill's description. This skill, protect-mcp-setup, is for projects that need a record of what the agent did and a way to stop certain actions before they run.

By default, Claude Code runs tools such as Bash, Edit, Write and WebFetch with no audit trail and no policy check. The protect-mcp setup closes those gaps in three ways: a Cedar policy is evaluated before each tool call, a signed receipt is written after each call, and a third party can verify the receipts offline without access to your system.

• Cedar policies (AWS's open authorization language) can allow or deny a tool call before it executes. A Cedar deny is authoritative.
• Ed25519 receipts record the name of each tool that ran, signed with your key.
• Verification runs locally with npx @veritasacta/verify and needs no server or account.

Install the skill from a ZIP or the Claude apps

You can add the skill to Claude Code by copying its folder into a skills directory. Download the ZIP from the agents directory page and unzip it into ~/.claude/skills/ to make it available to you in every project, or into .claude/skills/ inside a single project to limit it to that project.

If you use the Claude apps instead, open Settings, go to Capabilities, then Skills, and upload the ZIP there.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into .claude/skills/ in the project root
• Claude apps: Settings → Capabilities → Skills, then upload the ZIP

Set up the policy enforcement and hooks

The skill describes the full setup, and the enforcement itself comes from the plugin. Installing the plugin adds two hooks: PreToolUse, which evaluates each call against your policy before it runs, and PostToolUse, which signs a receipt after it finishes. The plugin's hook scripts are the parts that actually check and sign calls.

Then create a Cedar policy file named protect.cedar at the project root. The source includes a sample policy that allows read-only tools, allows a list of safe Bash commands, forbids chaining, redirection and rm -rf, and limits Write and Edit to paths inside the project. Adapt the paths to your own project before you rely on it.

Create a signing key once. The skill's guidance is to generate it only if ./protect-mcp.key does not already exist, because an existing key is never replaced. Add the key to .gitignore so it is not committed.

• Create ./protect.cedar at the project root and edit the paths in it.
• Keep ./protect-mcp.key private and listed in .gitignore.
• Receipts are written to ./receipts/receipts.jsonl by default.
• If the policy file is missing, the PreToolUse hook prints a warning and allows the call.

Ask for the skill with natural requests

You do not need a special command to trigger the skill. Claude loads it when your request matches its description, which concerns setting up projects that need cryptographic audit trails, policy-gated tool execution, or compliance-ready evidence of agent actions.

Requests that describe one of those goals are the most likely to trigger it. Be specific about what you want restricted or recorded so the setup matches your project.

• Set up protect-mcp in this project so every tool call gets a signed receipt.
• Write a Cedar policy that only lets Claude Code run git status, git diff and git log.
• Help me restrict file writes to this repository and block any path with .. in it.
• Add an audit trail of agent actions for this project that I can verify later.

Verify the receipts later

Verification checks every receipt against the public key in your key file, so you do not need to trust the person who ran the agent. Exit code 0 means every receipt verified, 1 means a receipt failed because it was tampered with, the wrong key was used, or a line was malformed, and 2 means the file could not be read.

Inside Claude Code, the plugin's slash commands do the same job. /verify-receipt checks a single receipt in its own file, and /audit-chain --last 20 reviews recent entries.

• Exit 0: every receipt verified
• Exit 1: a receipt failed (tampered, wrong key, or malformed line)
• Exit 2: the file could not be read

Know the limits before relying on it

A receipt records only the tool name. It does not record the tool's input or output, so it can show that a command ran but not what it did. Receipts also have no link to the previous receipt, which means a deleted line would go undetected.

Policy matching is best-effort. The Cedar like checks compare the raw command string, not a resolved path, and an allowed npm command runs arbitrary code. The skill is not a complete security boundary.

• Receipts show the tool name only, not input or output.
• A deleted receipt line is not detected by the chain itself.
• String matching can be bypassed; treat policies as a guardrail, not a sandbox.
• Setup needs Node.js and npm, and the first run fetches packages from the internet.