Writing rules
Policy Studio - allow, hold, or block a tool, lock a folder, set the default for everything else, and publish it to your plugin.
Policy Studio is where you decide what your assistant may do on its own. It publishes a policy profile that the ArmorClaude plugin enforces locally.
Open it at tools.armoriq.ai/policy-studio, or from the Policies screen with Open plugin Policy Studio.
Tool rules
A tool rule is one line: a tool name, and what should happen when the assistant calls it.
| Button | What happens |
|---|---|
| Allow | The call runs. |
| Hold | The call pauses and waits for a human to approve it. |
| Block | The call never runs. |
Tool names autocomplete from the ones your assistant actually has: Read, Grep, Glob,
Write, Edit, MultiEdit, Bash, WebFetch, WebSearch, Skill, Agent, and Task. The
wildcard * matches every tool.
A good first rule for most people is Bash set to Hold. Reading and searching stay
instant, and anything that runs a shell command waits for you.
Folder access rule
Give it one absolute path and the assistant is blocked from file-path tool calls underneath it. Use it for a credentials directory, a customer data folder, or anything you never want read.
This is not an OS sandbox. It blocks direct file-path tool calls under that folder. Shell commands, relative paths, symlinks, and tools that take no file path need enforcement of their own. Do not rely on this alone to protect secrets.
The path has to be canonical and absolute, with no . or .. segments.
Default for unmatched tools
Whatever your rules do not name falls through to this setting, and it is the single most important choice on the page.
- Allow unmatched tools. Permissive. Only what you named is restricted, so day one is not spent clearing prompts.
- Hold (ask) unmatched tools. Everything you have not explicitly allowed asks first.
- Deny unmatched tools. Strictest. Only what you explicitly allowed can run.
Check which one your workspace currently has before you rely on either reading. Move to Hold or Deny once you have watched a week of real sessions and know what your assistant reaches for. How it works shows what that week looks like.
Publishing
Save draft
Keeps your changes without affecting any running session. The page shows Saved draft, not yet published until you publish.
Activate for the plugin
Publishes a new version. The page confirms with the version number.
Restart your assistant session
A running session keeps the profile it started with. Start a new one to pick up the new version.
Verify a blocked call
Ask the assistant to do the thing you just restricted, and confirm it is stopped or held.
Publishing confirms the rule reached the server. It does not by itself confirm your machine is enforcing it, which is why step four exists. ArmorCodex profile sync is not supported by its current policy format.
If your workspace restricts who may publish, activation returns a message asking you to have an admin do it.
Rules the simple editor does not show
Policy Studio's editor covers the common shape: one rule, every agent, one tool, no conditions. The underlying format is richer, supporting principals (agent, user, org, role), resource types (workspace, file, directory, network, MCP server, secret), and conditions.
Anything more advanced than the editor understands is preserved unchanged and shown as a count of scoped or advanced rules, with the raw definition available to expand. Editing simple rules never rewrites or drops them.
Server-side policies are separate
The Policies screen lists policies that apply server-side to agents and MCP servers, with their own statuses (active, draft, shadow, inactive, expired) and enforcement actions (block, hold, allow and log, alert, quarantine).
Those are a different enforcement point from the plugin profile you publish here. A policy listed there is not the same object as a tool rule in Policy Studio, and the two screens say so.