Rolling Out GuardClaw Across a Team

You set up GuardClaw for yourself. It’s working. Your agent is supervised, your receipts are syncing, and your dashboard shows you what’s happening.

Now your team lead asks: “Can we do this for everyone?”

The answer is yes. And it doesn’t require a central server, a deployment pipeline, or an IT ticket. Each person installs GuardClaw locally. They connect to a shared workspace. Done.

This post walks through rolling out GuardClaw across a development team — shared policies, shared visibility, individual setup.

How team deployments work

GuardClaw’s team model is simple:

• One workspace = one set of security policies + one dashboard view
• Each developer installs GuardClaw on their own machine and connects to the workspace
• The detection engine runs locally on each person’s machine
• Receipts sync to the shared workspace so the dashboard shows everyone’s agent activity

Think of it like a team using the same linter configuration. Everyone has the tool installed locally. Everyone uses the same rules. The results are consistent.

Step 1: Create a workspace

The person setting up the team (usually the security lead or team lead) creates a workspace from the dashboard at guardclaw-dashboard.web.app.

A workspace comes with:

• An API key for the team
• A workspace ID
• Default security policies (which you can customize)

Step 2: Share the connection details

Give each developer two things:

• The API key (gk_...)
• The workspace ID (ws_...)

Each person runs:

brew install takeinterestinc/tap/guardclaw
guardclaw connect --api-key gk_team_key --workspace ws_team_workspace

That’s the entire setup for each developer. Their GuardClaw instance now uses the team’s policies and syncs receipts to the team’s dashboard.

Step 3: Set a shared policy

Put your guardclaw.yaml in the team’s code repository. When a developer clones the repo, they get the security policies alongside the code.

# guardclaw.yaml — committed to the repo
executors:
  http:
    enabled: true
    allowed_domains:
      - "api.yourcompany.com"
      - "registry.npmjs.org"
    require_https: true
    block_private_ips: true
  fs:
    enabled: true
    base_dir: "."
    allow_read: true
    allow_write: true
    allow_delete: false
  shell:
    enabled: true

This ensures everyone’s agents operate under the same rules. Changes to the policy go through pull requests, just like code changes.

What the security lead sees

The person managing the workspace sees everything in the dashboard:

• All agents across all team members, with their current status
• All receipts from everyone’s agent sessions
• Aggregate stats — total scans, block rate, threat breakdown across the team
• Individual filtering — filter by developer or agent to investigate specific sessions

What individual developers see

Each developer sees their own agent activity. They can view their receipts, check their denials, and understand why something was blocked.

The difference is scope. The security lead sees the full picture. Individual developers see their slice.

Handling different projects

If your team works on multiple projects with different security requirements, you have two options:

Option A: One workspace, multiple policies. Use per-project guardclaw.yaml files. The workspace is shared, but each project has its own policy. Receipts from all projects flow to the same dashboard.

Option B: Multiple workspaces. Create separate workspaces for projects with very different security needs. Each workspace has its own API key, policies, and dashboard view. The production API server gets a strict workspace. The internal tools get a lighter one.

Most teams start with Option A and split into multiple workspaces if the policies diverge significantly.

The rollout conversation

When you bring this to your team, here’s the pitch:

“We’re adding a security layer to our AI agents. It takes five minutes to set up. Your agent works exactly the same — it just can’t do things outside our security policies. If something gets blocked that shouldn’t be, tell me and we’ll adjust the policy.”

That’s it. No training session. No workflow change. No new tool to learn beyond the initial brew install and guardclaw connect.

The security benefit is immediate. The disruption is near zero.

Next post: what to do when GuardClaw blocks something — how to read the denial, decide whether it’s legitimate, and adjust your response.