Tool Permissions
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
- You define an allow list and a deny list per AI client in Tool Permissions
- Each agent receives the rules on its next check-in
- The agent merges them into the client's own configuration file
- 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
| Client | Enforcement surface |
|---|---|
| Claude Code | permissions.allow / permissions.deny in the user's settings.json |
| Cursor | MCP servers named in the deny list are removed from mcp.json (deny list only — an allow list has no effect here) |
| All others | No writable permission surface — use Firewall rules or, for Claude Code, Config Guard |
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
- Navigate to Tool Permissions in the sidebar, under Protection
- Pick the client you want to govern
- Enable the rule and list the tools to deny, to allow, or both
- 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 Permissions | Config Guard | |
|---|---|---|
| Writes to | The user's own client config | The machine-wide managed settings file |
| Can a user override it | Yes, until the next check-in restores the rules | No — managed settings outrank user settings and CLI flags |
| Applies to | Claude Code, Cursor | Claude 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.