Recipe Security

A recipe is executable automation. Its name and author can provide context, but only its workflow body and transitive dependencies describe what it can do.

Trust model

Echo records whether a recipe is Budgie-provided, community content, or self-authored, along with publisher metadata, a content hash, and any signature data. These are provenance signals, not substitutes for reviewing the executable actions.

The import review recomputes capabilities from the parsed workflow rather than trusting a cached manifest. A matching content hash establishes that the embedded body matches the hash in the envelope; it does not prove that the behavior is safe. Author identity, a source label, popularity, and a plausible description are also not substitutes for review.

Imported third-party recipes are runtime-gated for the exact actions marked for confirmation in the generated Action Reference. The prompt can deny, allow once, or always allow that action type for the recipe. Self-authored provenance does not prompt, so local authors must review their own side effects before testing.

Recursive permissions

Capability analysis is recursive. It walks actions nested under If / Else, Loop, Switch cases and default, and Try / Catch. When a workflow uses Run Workflow, analysis also walks the installed sub-workflow and attributes each hit to its source workflow.

Cycles between called workflows are stopped safely, but the analyzer records an unresolved sub-workflow separately because its capabilities cannot be known. The current import modal does not list those unresolved target ids, so inspect every Run Workflow node yourself. Treat a missing dependency as incomplete review: install or inspect the exact dependency first, then recompute the parent review.

Review the full call tree whenever a target workflow changes. A harmless parent can still delegate to a nested Shell, HTTP, file, keyboard, plugin, or other side-effect action. The root recipe's provenance is propagated into sub-workflow execution so a child cannot widen the root's runtime grant, but that gate does not replace inspection.

Side effects

Use the generated Action Reference for the current permission and runtime-confirmation value of every action. In particular, inspect these boundaries:

• Shell and Run AppleScript can execute arbitrary commands or automation. Read the complete command or script, including interpolated values.
• HTTP Request, downloads, and LLM calls can transmit input to another service. Confirm destinations, methods, bodies, provider profiles, and what upstream data reaches them.
• File actions can read, overwrite, move, copy, create, or delete local data. Resolve interpolated paths and check whether a target is recoverable.
• Paste and Keystroke send input to the currently focused application. A focus change can redirect their effect.
• Open App, Quit App, Switch to App, and Check App Running use the configured app name as their target; they do not retarget themselves to whichever app happens to have focus.
• Plugin actions are runtime-only and execute plugin-defined behavior. Review the installed plugin as well as the recipe call.
• LLM Prompt has no fixed model guarantee. Its text can include earlier outputs, so review the configured provider profile and never pass credentials through ordinary variables.

Runtime confirmation covers only the actions for which the generated reference says Yes. It is not a general prompt before every file, network, keyboard, app-control, or LLM operation. Step-by-step execution is also not a sandbox: choosing Next runs the real paused action.

Actions that can prompt are resolved exactly once before the permission check: their command, path, URL, or app name is interpolated (and, for Open App on macOS, resolved to an installed application) first, the prompt shows that resolved value, and the handler then executes the same value verbatim without interpolating again. Literal {{braces}} that arrive through an input therefore stay data on the way to the operating system.

A practical review

Before approval or the first run:

1. Read every visible node and every nested control-flow branch.
2. Follow each Run Workflow target recursively; stop on unresolved targets.
3. Trace inputs and outputs forward, especially clipboard, selected text, transcripts, environment values, files, and LLM results.
4. Compare every action with its generated permission and confirmation metadata.
5. Check exact commands, scripts, URLs, HTTP bodies, file paths, app names, keys, and plugin identifiers.
6. Use harmless test data. Never insert real secrets into Test run or ordinary workflow variables.
7. Start with one-shot only when the effects are already understood; use step-by-step for observation, not containment.

If behavior, target, provenance, or a dependency is unclear, cancel the import or do not run the workflow.