How to set organization policies for AI agents with Wield
To set an organization policy for AI agents, create an API key in your Wield dashboard, then set three things: the sites members may use, whether write recipes are allowed, and telemetry. Every member whose Wield uses that key gets the policy. A policy can only restrict. It cannot widen what the extension allows, and it cannot skip the Allow window for writes.
What a policy can and can't do
| Setting | Effect | What a member sees when blocked |
|---|---|---|
| Allowed sites | Only the listed sites appear and run | policy_denied. Nothing is sent |
| Writes: deny | Write recipes do not appear and cannot run | policy_denied. Nothing is sent |
| Telemetry: off | Outcome telemetry stays off, whatever a member sets | None |
Policies are a paid-plan feature. See pricing for plan details. This guide does not state prices.
Step 1: create an API key
Create the key in your dashboard on wield.run. Keys start with wld_ followed by 32 characters. The key is shown once. wield.run stores only its hash, so a lost key cannot be recovered. Revoke it and create a new one.
Choose the scopes the key needs:
| Scope | Allows |
|---|---|
registry:read | Fetching your organization's private recipes |
policy:read | Fetching the organization's policy |
builder:run | Building recipes from recordings |
recipes:write | Publishing private recipes |
Members of a policy-governed team need policy:read to receive the policy. Add registry:read if they also use private recipes.
Step 2: set allowed sites, writes and telemetry
In the dashboard, list the sites your agents may use. Turn writes off if agents should only read. Turn telemetry off for the organization. Save, and the policy takes effect for every key of the organization.
Step 3: members receive the policy
Each member gives Wield the key in one of three ways: the API key field in the Claude Desktop bundle, "api_key" in ~/.wield/config.json, or the WIELD_API_KEY environment variable in the AI app's server settings.
wield.run signs the policy with its registry key. wield-mcp checks the signature, enforces the policy and passes it to the extension, which enforces it too. If wield.run cannot be reached, the last verified policy stays in force, including offline.
Members can check the result. Ask the agent for status, which shows the policy when one applies. The doctor's Account section shows the same information with npx -y wield-mcp doctor.
Step 4: managed browsers
Organizations that manage browsers centrally can push the same settings to the extension as a managed policy, through Chrome Enterprise or an MDM tool. When both exist, the stricter one wins. A managed policy cannot relax the organization policy either.
What a policy does not change
- Every write still needs a member's click in the Allow window. A policy can turn writes off, but it cannot make a write happen without an Allow.
- Each Allow covers one run. Deny is the default, and two minutes without an answer count as a deny.
- A site in the allowed list still runs only the requests its recipe lists. The origin rules in the extension apply to every recipe.
FAQ
Can a member turn the policy off?
No. A member can remove the key, but then the organization's private recipes and policy stop applying to that member's Wield. Public recipes keep working under the extension's own rules, so an admin who needs a hard limit should also use managed browser policy.
What happens when a member is offline?
The last verified policy stays in force. A policy that was accepted before does not expire because the network is down.
Can I allow writes but review them first?
Writes always stop at the Allow window, so a person reviews every write request before it is sent. A policy can deny writes entirely, which is the stricter choice.
Does the policy cover recipes my team builds?
Yes, when the recipes are private to your organization. Private recipes are signed with your organization's own key, and the policy controls which sites and writes may run.