Give your ops team's AI agents access to internal tools

#What an internal-tool recipe looks like

Private recipes use the id <org>:<site>/<slug>, for example acme:intranet.acme.com/search-people. Your agents see them next to the public recipes. They are stored for your organization only, and they are served only with a key that has the registry:read scope. Each version is signed. Versions only go up, and older versions stay available for pinning and fallback.

#Record it

1. Ask your agent to record the task, for example "Record how I check an order's status on our back office and make it a Wield recipe." The agent calls request_recipe in record mode.
2. Your browser opens the site. Do the task once, then click Done.
3. Review the page. It lists every request that would be sent. Click Send, or Discard to stop. Nothing leaves your computer before this click.
4. The builder drafts a recipe from the sanitized recording.
5. Your browser tests the draft with its example parameters. Only your browser can reach your account, so the test runs there.
6. The recipe is saved privately to your organization.

Before review, the extension sanitizes the recording on your computer. Typed values become placeholders. Cookies and auth headers are removed. Tokens are replaced with a redacted marker and a one-way fingerprint. Personal data such as emails, phone numbers and names is redacted. Responses keep only their structure. The review page refuses to send if a typed value or an auth header survived.

If the builder is unavailable, or your plan's builds for the month are used up, the recording stays on your computer and the agent can retry later with its rec_id.

Publish your own files with PUT /api/v1/private/recipes/<site>/<slug> and a recipes:write key. They get the same schema checks and lint as public recipes.

#Roll out with policies

Admins set the policy in the dashboard. It applies to every member whose Wield uses a key from the organization.

A policy can only restrict. It cannot add sites, and it cannot skip the Allow window. Every write still needs a click from the user. wield.run signs the policy, and wield-mcp checks the signature. The last verified policy stays in force while the machine is offline.

Organizations that manage browsers centrally, through Chrome Enterprise or MDM, can push the same settings as a managed policy. When both exist, the stricter one wins.

#API key scopes

A key is shown once. wield.run stores only its hash, so a lost key must be revoked and replaced. The key is sent only to wield.run.

#What the recorder can't do

• Constants. A value such as an API version or a client id may need to be filled in at the test run.
• Writes are not tested automatically. Write recipes are drafted, but testing them would send real data. Run one under supervision first. The Allow window still protects every write.
• Some flows. A flow with several setup pages, or a CAPTCHA on every run, may not be recordable. Ask for it with request_recipe instead.

#FAQ

#Can other Wield users see our private recipes?

No. Private recipes never appear in the public index.

#Does our internal data reach wield.run?

Results go from the extension to wield-mcp and then to your AI app. They never pass through wield.run. A recording is sanitized on your computer before you review it. The builder on wield.run receives only the sanitized version.

#Can we stop agents from writing?

Yes. The writes-deny policy removes write recipes and blocks them. The Allow window applies to any write that remains.

#What does it cost?

This page doesn't list prices. See pricing. Audit export is part of the paid plans.