The Swif OpenClaw Tools Access Policy controls which tools OpenClaw agents may use on managed devices.

Administrators can establish a base tool profile, allow or deny individual tools and tool groups, apply provider-specific and sender-specific restrictions, control tools inside sandboxed sessions, restrict elevated command execution, manage agent-to-agent access, and limit session visibility.

The policy supports:

This is a security-sensitive policy. An overly broad configuration can allow an AI agent to execute commands, modify files, interact with external services, communicate through connected channels, or access other sessions. Begin with least privilege and test each permitted workflow before expanding access.

The policy configures OpenClaw tool access. It does not install the OpenClaw gateway or the Swif Agentic Security agent.

OpenClaw evaluates tool access through multiple layers. The effective result is the intersection of the applicable profile, allow rules, deny rules, provider or sender restrictions, sandbox rules, and other runtime security controls.

The most important rules are:

Important: Deny rules take precedence. If a tool matches both an allow rule and a deny rule, it remains denied.

Tool names are case-insensitive in OpenClaw allow and deny policies. Wildcards such as * are supported.

For an initial enterprise deployment, use the following least-privilege baseline:

For a managed software-development workflow, you can use the coding profile, but consider denying unrestricted runtime execution and file modification unless those capabilities are required:

If developers need read-only filesystem access, deny individual mutation tools instead of denying group:fs, because group:fs also contains read.

Default-profile notice: Explicitly select a Tool Profile when creating the policy. Native OpenClaw commonly initializes an unset local profile as coding, while Swif policy versions can display a more restrictive profile in the editor. Selecting the value explicitly prevents the effective profile from depending on an inherited or previously applied default.

The minimal profile permits only basic session-status access.

Use it when an agent should have no general filesystem, command-execution, web, messaging, or cross-session tools unless you add specific exceptions.

The coding profile is intended for software-development workflows. It includes tool groups for:

This profile provides significant capability. Review filesystem mutation, command execution, external access, and session tools before assigning it to production devices.

The messaging profile supports messaging and conversation-oriented workflows, session access, subagents, and related coordination tools. It can also expose configured MCP servers through bundle-mcp.

Use sender-specific rules when a connected channel accepts requests from multiple people.

The full profile applies no profile-level tool restriction. It is equivalent to leaving the native OpenClaw profile unrestricted.

Do not use full as a convenience default. Assign it only when the device, user, connected channels, credentials, workspace, and runtime isolation have been reviewed for unrestricted tool access.

Tool groups make it easier to manage related capabilities together.

Group membership can change as OpenClaw evolves. Review the current OpenClaw tools configuration reference before using a group in a sensitive policy.

Sets the base tool allowlist before additional allow and deny rules are applied.

Available values:

Always choose this value explicitly.

Creates an explicit global tool allowlist. Entries can include:

Examples:

Use exact tool names whenever practical. A broad group or wildcard can automatically include capabilities added by a future OpenClaw release.

Creates an explicit global denylist. Deny rules win over profile and allow rules.

Examples:

write and apply_patch are separate tool IDs. Denying write does not automatically deny apply_patch. To block all filesystem operations, deny group:fs. To preserve read access while blocking changes, deny each mutation tool individually.

Applies additional rules to a particular AI provider or provider/model combination.

Each entry contains:

OpenClaw applies the base profile, then the provider profile, followed by provider allow and deny rules. Use provider policies to reduce access for a provider or model that should not receive the full global tool set.

Do not configure Allowed Tools and Also Allowed Tools in the same provider entry. OpenClaw rejects a scope containing both. Use one of these patterns:

Restricts tools according to the verified requester identity supplied by an OpenClaw channel adapter.

The Name field identifies the sender rule. Supported key formats include:

Each sender entry can contain a Tool Profile, Allowed Tools, Also Allowed Tools, and Denied Tools.

Sender rules provide defense in depth. They do not replace channel authentication or access controls, and they do not authenticate names or instructions merely included in message text.

Use the wildcard sender * to establish a restrictive fallback for requesters who do not match a more specific rule.

The Sandbox Tool Policy creates an additional allow and deny gate for sessions that are already sandboxed.

It supports:

This setting does not enable OpenClaw sandbox mode by itself. It controls tool visibility within a sandbox created by the applicable OpenClaw agent or runtime configuration.

For MCP or plugin tools to remain available inside a sandbox, you may need to add one of the following to Also Allowed Tools:

You can instead allow a specific plugin ID, exact MCP tool name, or an appropriately scoped wildcard. Avoid group:plugins when only one integration is required.

Controls whether the exec tool can run outside the sandbox.

For each Allow From entry:

The Swif policy default is Disabled.

Warning: Elevated execution bypasses sandbox isolation for the applicable command. Enable it only for explicitly identified senders, and combine it with operating-system permissions, logging, and a narrowly scoped command workflow.

Do not enable elevated execution with an empty or unverified sender configuration.

Controls whether one OpenClaw agent can target another agent through supported session tools.

The Swif policy default is Disabled.

When enabled, list every approved participating agent. OpenClaw requires both the requesting and target agent IDs to match the allowlist.

Important: In native OpenClaw behavior, an omitted or empty agent allowlist can be treated as unrestricted when agent-to-agent access is enabled. Do not enable this feature until Allowed Agents contains the complete intended set. Review the policy after deleting or renaming an agent.

Controls which sessions can be targeted by supported session tools such as session listing, history, search, send, and status operations.

The Swif policy default is tree.

Use self for the narrowest isolation. Use tree when a workflow requires subagents. Avoid all unless administrators have reviewed cross-agent access and the risk of exposing other users' or agents' session history.

Sandbox runtime settings can further restrict session visibility even when this policy selects a broader scope.

For the general assignment workflow, see Assigning policies to devices or groups.

Use this pattern for an agent that needs research access but should not read files, run commands, modify the device, or interact with other sessions.

This preserves much of the coding workflow while blocking command execution and common filesystem mutation tools. Test the exact agent because some development workflows may require one of the denied tools.

Use verified channel and sender IDs. Do not rely only on a display name when a stable sender ID is available.

After deployment:

Do not test elevated execution, deletion, external messaging, or cross-agent access with production data or credentials.

Note: A successful policy status confirms that Swif delivered the configuration. It does not prove that every rule behaves as intended for every provider, plugin, channel, or OpenClaw version. Functional testing is required.

Use the Swif Agentic Security Logging Policy alongside this policy when administrators need an audit record of supported agent activity.

The tools access policy determines which tools an OpenClaw agent may use. The logging policy determines whether supported activity is reported for monitoring and investigation. Enabling logging does not grant a tool, and allowing a tool does not automatically enable logging.

Check the following:

Remember that deny rules win over all matching allow rules.

Sandbox tool policy is an additional gate. Add only the required plugin ID, MCP tool name, or narrowly scoped wildcard to Also Allowed Tools.

Use bundle-mcp for OpenClaw-managed MCP servers or group:plugins for all plugin-owned tools only when that broader access is intended.

Check for these common causes:

Correct the policy, redeploy it, and review the new deployment report.

Confirm that:

Do not broaden the sender allowlist merely to make a failed test pass. First verify the actual channel identity supplied to OpenClaw.

To reduce access, update the policy with a narrower profile or additional deny rules, then verify the result in a new session.

To stop managing OpenClaw tool access through this policy:

Removing a policy assignment does not necessarily restore the configuration that existed before Swif managed it. Do not remove the assignment while a broad or privileged policy is the last applied state.

The Swif OpenClaw Tools Access Policy provides centralized control over OpenClaw tool access on macOS, Windows, and Linux devices.

For a secure deployment: