Why signed recipes matter for AI agent safety
Wield signs the recipe index and every recipe with Ed25519. The extension and wield-mcp refuse any recipe that is unsigned, signed by an unknown key or changed after signing. Recipes are data, not code, so a recipe cannot run JavaScript in the page. Requests also stay on the https origins that the recipe lists.
Attack paths for agent tools
An agent tool is a new target. Anyone who can change a recipe file, or the channel it arrives through, could try to:
- swap a recipe for one that sends requests to another host,
- add script that runs in the site's page,
- hide a write request inside a read recipe,
- replay an older version in place of the current one.
Each path has its own check. The table shows what stops it.
| Attack | What stops it |
|---|---|
| Changed or swapped recipe | An Ed25519 signature over the exact response body. The error is recipe_unsigned, and nothing is sent to the site. |
| Recipe signed for another context or organization | The signature covers the context (index, recipe or policy) and the scope (public, or your organization). A mismatch is refused. |
| Replayed old index | An index older than one already accepted is refused. |
| Requests to another host | Requests go only to the https origins the recipe lists. Redirects to other hosts are not followed. |
| Recipe that sets session headers | Recipes may not set Cookie or Host headers. The interpreter refuses them. |
| Hidden write | A write stops before its first request and shows a window with every request and its body. Deny is the default. |
What signing covers
Each signed response carries a header with a key id, a context and the signature. The signature covers the context, the scope and the SHA-256 hash of the exact response body. Changing one byte breaks it.
The checks run every time, not once:
- Cached copies are verified again each time they load.
- An index older than one already accepted is refused, so old versions cannot be replayed.
- New registry keys are trusted only when an existing trusted key endorses them.
wield-mcp doctorshows whether signatures are enforced on your install and which keys it trusts.
One gap is deliberate and visible. Recipes you load from a local folder for development (WIELD_RECIPES_DIR) are not signed, and status says so.
Recipes are data, origins are limited
A recipe is a small JSON file. It describes the HTTP calls that a site's own pages make, and it contains no code. Wield runs it in a tab of that site, with the browser session you already have. Wield never reads, copies or sends cookies or passwords. A recipe may read only the named tokens it declares, such as a CSRF token. Any derived token is replaced with [redacted] in results and logs.
The same limits apply to every recipe, public or private: 12 steps, 40 requests, 5 MB per response and 60 seconds per run.
Reviewers also check the origins. Every origin in a recipe must be used by a step. A host outside the site's own domain must be named and explained in the recipe, so a reader can see where data goes.
Public review and private recipes
A public recipe passes three gates before it is listed: automated schema and safety checks, a maintainer review, and a live run in a browser. The review asks whether every origin belongs to the site, whether session data goes anywhere other than the site, and whether every write is marked as a write.
Private recipes pass the same schema checks and lint. Each one is signed with your organization's own key. That key is delivered inside the policy that the registry signs, so Wield refuses a private recipe that your key has not signed. Private recipes never appear in the public index.
FAQ
Does signing mean a recipe is safe?
No. A signature shows that the file came from Wield's registry and has not changed since. Review decides whether a file should be published at all. Read a recipe's terms note and its provenance before you rely on it for a site.
What happens when a signature check fails?
wield-mcp refuses the recipe with the error recipe_unsigned, and nothing is sent to the site. Ask your agent for status, or run npx -y wield-mcp doctor, to see which keys your install trusts.
Can I run unsigned recipes?
Yes, but only from a local folder that you set with WIELD_RECIPES_DIR for development. Those recipes are not signed, and status shows that. Public recipes always need a valid signature.
Do private recipes get the same protection?
Yes, with one difference. Each private recipe is signed with your organization's key rather than the public one. Members receive it only with an API key that has the registry read scope. See private recipes for internal tools.