Your First SafeClaw Policy in 5 Minutes

A SafeClaw policy defines exactly what your AI agent can and cannot do — every file it can write, every command it can run, every network request it can make. This guide takes you from zero to a working, enforced policy in five minutes. No prior experience with agent safety required.

What You Will Build

By the end of this guide, you will have:

• SafeClaw installed and connected
• A deny-by-default policy that blocks all agent actions unless explicitly allowed
• Specific allow rules for your agent's legitimate actions
• Simulation mode running so you can verify the policy before enforcing it
• A tamper-proof audit trail recording every action decision

Prerequisites

• Node.js 18 or later
• An AI agent or tool that takes actions (Cursor, Copilot, Windsurf, Claude, OpenAI, LangChain, CrewAI, AutoGen, or any MCP-compatible agent)
• 5 minutes

Step 1: Install SafeClaw

Open your terminal and run:

npx @authensor/safeclaw

This installs the SafeClaw client. It has zero third-party dependencies — nothing else is downloaded, nothing else runs. The client is 100% open source under the MIT license.

Step 2: Get Your Free API Key

Visit safeclaw.onrender.com to access the browser dashboard and setup wizard. Create a free account — no credit card required. You will receive a 7-day renewable API key.

The setup wizard walks you through connecting SafeClaw to your agent. Select your agent framework from the list (Claude, OpenAI, LangChain, CrewAI, AutoGen, MCP, Cursor, Copilot, or Windsurf) and follow the integration instructions.

Step 3: Define Your Policy

A SafeClaw policy starts with deny-by-default — nothing is allowed until you say so. Then you add explicit allow rules for the actions your agent needs.

Here is a starter policy for a coding agent that should be able to read and write files in a project directory and run safe commands, but nothing else:

{
  "defaultAction": "deny",
  "rules": [
    {
      "action": "file_read",
      "path": "/home/user/my-project/**",
      "decision": "allow"
    },
    {
      "action": "file_write",
      "path": "/home/user/my-project/src/**",
      "decision": "allow"
    },
    {
      "action": "shell_exec",
      "command": "npm test",
      "decision": "allow"
    },
    {
      "action": "shell_exec",
      "command": "npm run build",
      "decision": "allow"
    },
    {
      "action": "network",
      "domain": "registry.npmjs.org",
      "decision": "allow"
    }
  ]
}

What this policy does

• file_read: The agent can read any file inside /home/user/my-project/ and its subdirectories. It cannot read .env files, SSH keys, or anything outside the project.
• file_write: The agent can write only to the src/ directory. It cannot modify config files, package.json, or the policy itself.
• shell_exec: The agent can run npm test and npm run build. It cannot run rm, curl, chmod, or any other command.
• network: The agent can contact the npm registry. All other outbound requests are denied.
• Everything else: Denied. If an action does not match an allow rule, it is blocked.

Customizing your policy

Adjust the paths, commands, and domains to match your project. The key principle: only allow what the agent actually needs. If you are unsure, leave it denied — you can add permissions later based on what simulation mode reveals.

Step 4: Enable Simulation Mode

Before enforcing your policy, run it in simulation mode. In this mode, SafeClaw evaluates every action against your policy and logs the decision — but does not actually block anything. This lets you verify that:

• Legitimate agent actions are allowed
• Dangerous actions are denied
• No false positives are breaking your workflow

• Denied actions that should be allowed — Add an allow rule for these
• Allowed actions that should be denied — Tighten your path or command patterns
• Unexpected actions — Actions you did not know your agent was performing (this alone makes simulation mode worth running)

Step 5: Switch to Enforcement Mode

Once you are satisfied with the simulation results, switch your policy to enforcement mode. Now SafeClaw will actively block any action that violates your policy. The evaluation happens in sub-millisecond time — there is no perceptible delay to your agent or your workflow.

From this point forward:

• Every agent action is evaluated before execution
• Denied actions never reach your infrastructure
• Every decision is recorded in a tamper-proof audit trail using SHA-256 hash chains
• You can review all activity in the browser dashboard

Understanding the Audit Trail

Every action your agent takes — whether allowed or denied — is recorded with:

• Timestamp
• Action type (file_write, file_read, shell_exec, network)
• Target (file path, command, domain)
• Policy decision (allow, deny, flag)
• Hash chain entry for tamper-proof verification

Common First-Policy Patterns

For a coding assistant (Cursor, Copilot, Windsurf)

Allow file_read and file_write within the project directory. Allow shell_exec for build and test commands only. Deny all network except package registries.

For a research agent

Allow file_read broadly. Allow file_write only to a designated output directory. Allow network to specific research APIs. Deny shell_exec entirely.

For a CI/CD agent

Allow shell_exec for specific build, test, and deploy commands. Allow file_read and file_write within the build directory. Allow network to your artifact registry and deployment targets only.

For a multi-agent system (LangChain, CrewAI, AutoGen)

Create separate policies for each agent role. The orchestrator agent might have broader read permissions, while worker agents are restricted to their specific task scope.

What Happens Next

Your first policy is running. Here is what to do over the coming days:

1. Review the audit trail daily for the first week — understand what your agents are actually doing
2. Tighten rules based on observed behavior — remove permissions that are not being used
3. Add simulation-mode rules for new capabilities before allowing them in production
4. Share the dashboard with your team — agent safety is a team responsibility

Troubleshooting

Agent actions are being denied that should be allowed: Check your path patterns. Ensure you are using ** for recursive directory matching. Add the specific action to your allow rules.

Simulation mode shows unexpected actions: This is working as intended. You are discovering what your agent actually does versus what you thought it did. Decide whether each unexpected action should be allowed or denied.

Policy changes are not taking effect: Ensure you have saved and deployed the updated policy through the dashboard. Policy updates take effect immediately — there is no cache delay.

Summary

You now have action-level gating on your AI agent. Every action is evaluated against your policy, every decision is logged, and your infrastructure is protected by deny-by-default architecture. This took five minutes. The alternative — discovering what an uncontrolled agent can do to your systems — takes much longer to recover from.

For more: visit safeclaw.onrender.com for the full dashboard, or explore authensor.com for documentation and advanced policy patterns.