Security

Configure sender controls, folder policy, and network guard in Msty Claw

Security in Claw is practical and layered: control who can trigger agents, what files they can access, and where they can connect. The goal is safe execution without blocking useful work.

Open Settings > Security to configure baseline controls.

Security model at a glance

Use these controls together:

  • Sender Groups: who can invoke agents and channel presets
  • Allowed Folders: where agents can read/write
  • Blocked Patterns: sensitive paths blocked even inside allowed roots
  • Network Guard: outbound network restrictions
  • Approvals: confirmation checkpoints for higher-risk actions
  • Rules: event-based guidance, blocking, follow-up, and checks

These controls are most effective as a combined policy. Relying on only one layer usually leaves avoidable gaps.

Sender controls

Use Sender Groups to define who can run what.

  • Create reusable groups (team, service users, trusted operators)
  • Assign groups to agents and channel presets
  • Use Anyone only for intentionally open contexts

Guidance:

  • Keep production agents restricted by default
  • Avoid reusing wide-open groups on privileged agents

If agent behavior is sensitive, sender policy should be explicit and auditable before broad enablement.

Folder policy

Use Allowed Folders and Blocked Patterns together.

  • Allowed roots define agent operating boundaries
  • Each root can be read/write or read-only
  • Blocked patterns protect sensitive material inside allowed roots

This two-layer approach lets you keep execution practical while still protecting known sensitive paths.

Common blocked patterns include:

  • .ssh
  • .gnupg
  • .aws
  • .env
  • credentials
  • private_key
  • id_rsa
  • id_ed25519

Guidance:

  • Start with project-specific roots, not broad home-directory roots
  • Prefer read-only access for reference sources

When in doubt, start narrower and expand only after validated need.

Network Guard

Available presets:

  • Recommended
  • Privacy
  • Strict
  • Approved Only

You can also define custom allow/deny hosts for finer control. Network policy should reflect workflow intent: allow only what the agent actually needs to complete its job.

Guidance:

  • Start with Recommended
  • Move to stricter presets for sensitive automations
  • Treat Approved Only as production-hardened mode

For internet-facing automations, revisit host allow/deny rules regularly as dependencies change.

Airlock policy controls

Airlock adds website-level policy controls for agent network access. Use it when workflows need explicit allow/block decisions at host level.

Use Airlock to:

  • Restrict web-enabled agents to approved domains
  • Block known risky hosts even when network access is enabled
  • Keep outbound access policy auditable and repeatable across agents

Airlock is most effective with containerized agents and a narrow policy-first rollout. For setup and operations, see Airlock.

Approval model

Claw can request approvals for sensitive actions. Keep approvals enabled until policies are stable and tested under real workflows.

Useful operator loop:

  1. Review approval prompts during rollout
  2. Adjust agent scope and permissions
  3. Re-run and confirm fewer unnecessary prompts

Rules as guardrails

Rules add event-based control around chats and tool use. They can add guidance before Claw replies, stop matching actions before they run, append notes after actions, request follow-up, or run a check command after matching work.

Security-oriented examples:

  • Block risky shell commands until the operator reviews them
  • Add release or production-change guidance before matching prompts
  • Request a follow-up review after file edits
  • Run a narrow validation command after matching actions finish

Rules complement approvals and folder/network policy. They do not replace hard security controls, and automatic command rules should be scoped narrowly. For setup and examples, see Rules.

Practical security baseline

  1. Restrict sender groups before enabling shared channels
  2. Limit each agent to project-specific folders
  3. Add organization-specific sensitive patterns to blocklist
  4. Use a conservative Network Guard preset for production agents
  5. Configure Airlock for internet-enabled container agents
  6. Add Rules for recurring risky patterns
  7. Keep approval prompts on for high-risk capabilities

This baseline is intentionally conservative. Relax controls only after you can show repeated safe behavior in real workflows.

Related detail pages

Setup
Guided first-run setup for a stable Msty Claw workspace
Agents
Create, run, and manage agents in Msty Claw