Skip to main content

Tool Permissions

Plan requirement

Tool Permissions require the Starter plan or above, and are included in the 14-day trial.

Tool Permissions define which tools an AI client may use. Where a client keeps a writable permission list of its own, Sielum maintains that list on every endpoint — so the rule lands inside the tool itself instead of relying on a network block.

How it works

  1. You define an allow list and a deny list per AI client in Tool Permissions
  2. Each agent receives the rules on its next check-in
  3. The agent merges them into the client's own configuration file
  4. The client enforces them itself the next time it runs

Rules are merged, not replaced: existing entries in the user's configuration are preserved and your allow/deny entries are added to them. The agent writes the file in place, preserving ownership when it runs as a service on behalf of a user.

Where enforcement lands per client

ClientEnforcement surface
Claude Codepermissions.allow / permissions.deny in the user's settings.json
CursorMCP servers named in the deny list are removed from mcp.json (deny list only — an allow list has no effect here)
All othersNo writable permission surface — use Firewall rules or, for Claude Code, Config Guard
Why not every tool

Only some AI clients expose a configuration file that governs what the tool may do. For the rest there is nothing to write into, and the honest answer is a network-level control rather than a setting that looks like enforcement but is not.

Configuring rules

  1. Navigate to Tool Permissions in the sidebar, under Protection
  2. Pick the client you want to govern
  3. Enable the rule and list the tools to deny, to allow, or both
  4. Save — the rules reach each endpoint on its next check-in

Denying is the stronger statement. For Claude Code the deny entry is written alongside whatever the user has allowed, and Claude Code resolves deny first. For Cursor, a denied MCP server is deleted from the config outright; if the user adds it back, the next check-in removes it again.

Relationship to Config Guard

Tool Permissions and Config Guard work at different levels:

Tool PermissionsConfig Guard
Writes toThe user's own client configThe machine-wide managed settings file
Can a user override itYes, until the next check-in restores the rulesNo — managed settings outrank user settings and CLI flags
Applies toClaude Code, CursorClaude Code

For a rule that a user must not be able to work around, use Config Guard. For day-to-day tool hygiene across the clients that support it, use Tool Permissions.