How to give AI agents your internal tools with private recipes

#When private recipes make sense

• Intranet and back-office pages that no public registry should list.
• Internal tools that a team already uses in its own browser.
• Sites where the organization wants control, such as limits on which sites can run or whether writes are allowed.

If a public recipe already covers the site, use that one. Private recipes are for what the public registry does not cover.

#Create one

There are two ways in.

1. Record it. Ask your agent to record how you do the task. The agent opens the site in your browser, and you do the task once and click Done. Review the list of what would be sent, then click Send. The builder drafts a recipe, your browser tests the draft, and the recipe is saved privately to your organization. Recording needs a Pro or Team plan.
2. Publish your own file. Send the recipe to PUT /api/v1/private/recipes/<site>/<slug> with an API key that has the recipes:write scope. Your file gets the same schema checks and lint as a public recipe.

Recording removes cookies, auth headers and every typed value on your computer before you review it. A private recipe then runs under the same rules as a public one: origins are limited, a write needs your Allow, and no token leaves the session.

#How they are stored and signed

• Ids. Your agent sees a private recipe as <org>:<site>/<slug>, for example acme:intranet.acme.com/search-people. It sits next to the public recipes in the same list.
• Signing. Each private recipe is signed with your organization's own key. Wield refuses a private recipe that is not signed. The key is delivered inside the policy that the registry signs.
• Versions. Versions only go up. A new version leaves the old ones available for pinning and for fallback.
• Visibility. Private recipes are stored for your organization only. They never appear in the public index.

#Who can run them

Members run private recipes with an API key that has the registry:read scope. Keys have four scopes: registry:read, policy:read, builder:run and recipes:write. A key is shown once and stored only as a hash. If a key is lost, revoke it and create a new one.

Organization roles are owner, admin and member. Admins set one policy for every member who uses a key from the organization:

A policy can only restrict. It cannot widen what the extension allows, and it cannot skip the Allow window. Every write still needs the user's click.

#Before you roll out

• Run each recipe yourself once, with a test value, and read the output.
• Set the policy before you share a key, so the allowed sites are right from the start.
• Decide whether writes are needed at all. If not, deny them.
• Check what the internal site's own rules say about automated use, as you would for a public site.
• Tell your team that every write stops for their Allow.

#FAQ

#Does my internal data go to wield.run?

Private recipes run in your browser. wield.run receives the requests for your private recipes and policy, made with your key. A recording is sent only after you review it and click Send, and it has already been sanitized on your computer.

#Can a private recipe appear in the public list?

No. Private recipes are stored for your organization and served only with a key that has the registry read scope.

#Do private recipes need a paid plan?

Yes. Private recipes, the recipe builder and organization features are part of the paid plans. See pricing for details.

#Can an admin see what members ran?

Each member's logs stay on that member's computer, and they record the host, path, status and timing, never bodies or query values. Audit export is part of the paid plans.