Inspiration
CyberChef provides security analysts, developers, and students with 503 browser-based Operations covering encoding, compression, cryptography, parsing, and data analysis. Even when users know the intended result, they may not know which Operations provide it, which arguments those Operations require, or how to arrange multiple Operations.
The author of CyberChef issue #2691 reported working with unreadable data whose algorithms and processing order were unknown. Magic returned no useful Recipe, and manually testing dozens of likely algorithms in different orders did not recover the expected result. The author reported that a locally run AI model later identified the algorithms, arguments, and execution order.
The issue discussion explained that sending processed data to an external AI service would conflict with CyberChef’s browser-local processing model. The issue was then closed as not planned.
With CyberChef continuing to process the data in the browser, RecipeBridge focuses on two cases: locating and configuring relevant Operations among 503 choices when the intended result is known, and determining a possible Operation sequence when the processing chain is unknown.
What it does
The Agent can search CyberChef’s 503 Operations, inspect argument definitions, read a redacted view of the Recipe state, submit revision-checked Recipe changes, request a Bake, and use bounded Magic analysis to select subsequent actions.
WebMCP provides the Agent with Operation metadata, Recipe structure, execution state, and limited analysis signals. Raw Input, raw Output, current Recipe argument values, Register captures, Magic previews, and candidate arguments remain inside the browser page and are excluded from WebMCP results.
Every Agent change appears in the existing CyberChef interface. The user can inspect and edit the Recipe, stop WebMCP access, and restore the Recipe state that preceded the Agent’s latest change while that snapshot remains valid.
The access audit classifies each Operation according to its behavior and side effects:
direct(447): Operations that use CyberChef’s standard in-page processing flow.approval(51): Operations involving network access, signing and key generation, OTPs, rich-content presentation, nondeterministic results, Recipe flow control, or Input-derived arguments. These require one-use user approval.blocked(5):Magicuses a dedicated analysis flow. The other four still involve direct Input changes, remote resources, or SVG rendering risks.excluded(1): An internal validation Operation that is omitted from the product catalog.
How I built it
RecipeBridge registers six fixed workflow tools through WebMCP:
search_operationsget_operation_detailsget_recipe_stateapply_recipe_patchbake_recipeinspect_output
The fixed tool set controls the amount of context loaded during discovery. Search and detail tools provide CyberChef’s generated Operation metadata on demand, allowing the Agent to load only the names, options, defaults, and argument definitions required for the current task. Recipe arguments continue to use CyberChef’s existing metadata and validation rules.
User and Agent changes pass through the same Recipe transaction. Each step has a stable ID, and each Recipe has a revision number. The Agent must provide the expected revision when submitting a change. CyberChef prepares and validates the complete change before updating the Recipe model and visible interface. A stale request fails and leaves the workspace unchanged.
Each Bake records the Recipe revision, Input version, execution-options version, Output tab, and bakeId. These identifiers prevent delayed Web Worker or Magic results from replacing Output produced by a newer run.
The page stores complete Magic candidate Recipes and their arguments in memory. inspect_output analyzes up to the first 1,000 bytes of the current Output and returns filtered analysis signals, candidate IDs, ranks, and Operation names. When the Agent applies a candidate ID, the page sends the stored Recipe through the standard access checks, validation, approval, and transaction flow. Magic ranking guides subsequent analysis, while the user verifies the result through the visible Output.
Tool results are generated through a fixed field allowlist. Magic-derived results are also bound to the current Output tab and bakeId, preventing stale analysis results from being returned.
The browser or Agent host can still observe the page and URL, so the project recommends disabling CyberChef’s URL updates before processing sensitive data.
Challenges I ran into
Exposing a large application through a small tool surface
Registering a separate tool for each of hundreds of Operations would increase discovery context and make the interface harder to use. Six workflow tools provide a stable interface, while catalog search and pagination expose CyberChef Operations on demand.
Coordinating a workspace shared by a user and an Agent
CyberChef already supports manual editing, Auto Bake, multiple tabs, background Magic analysis, and Web Workers. Agent changes also require handling stale revisions, overlapping runs, and delayed results. Stable step IDs, atomic Recipe transactions, fixed Bake target information, and provenance checks give each state change clear ownership.
Providing useful information while protecting user data
The Agent needs feedback to refine a Recipe. Limited analysis signals and candidate references stored inside the page support further analysis while keeping raw data, key material, and decoded Output outside WebMCP results.
Adapting to an evolving WebMCP implementation
WebMCP remained a draft during the challenge, and available WebMCP hosts did not forward invocation cancellation signals consistently. RecipeBridge accesses the browser API through an isolated adapter with feature detection. Page lifecycle checks, session shutdown, timeouts, and stale-result checks protect Recipe and Output state when a host cannot cancel an active invocation.
Reusing upstream behavior accurately
An early design duplicated Operation rules through separate profiles, which could diverge as CyberChef changed. The revised design reads CyberChef’s defaults, argument structures, fixed options, and validation rules directly. A separate access audit handles only WebMCP permission classification.
Accomplishments
The deployed fork supports the complete visible workflow, including Operation discovery, Recipe editing, user approval, Bake execution, Output inspection, and Magic candidate application. Browsers without WebMCP support continue to load the existing CyberChef interface normally.
The implementation reviews every generated Operation and defines explicit behavior for the direct, approval, blocked, and excluded classifications. It also handles stale Recipe revisions, rejected or expired approval requests, Operation runtime failures, interrupted or superseded runs, and page-scoped collaboration session shutdown.
Current automated validation includes 507 passing Node API tests and 12 passing Chrome WebMCP browser scenarios. Independent testing of the deployed site covers 35 representative workflows across encoding, compression, cryptography, parsing, analysis, Recipe control, approvals, failure handling, and privacy checks.
What I learned
Shared-workspace development should begin by mapping each state owner, revision, authorization, and completion transition. This prevents user actions, Agent requests, and asynchronous Worker results from overwriting one another
A large capability catalog should use a small, stable workflow API with on-demand metadata. This limits the Agent’s discovery context without maintaining hundreds of separate tool contracts.
Accurate implementation begins with understanding the business meaning of each data value. That meaning must remain consistent across WebMCP tool descriptions, input arguments, result fields, validation, and tests. This reduces ambiguity when the Agent selects Operations, configures arguments, and interprets results.
What’s next
Future work will improve resource-intensive Intensive Magic analysis, expand interoperability checks as browser implementations evolve, and provide clearer candidate explanations while protecting candidate arguments and raw Output. User feedback can also guide adjustments to Operation access classifications and approval wording.
RecipeBridge is currently an experimental fork. Manual review of the added and modified code remains limited, so further review and practical testing are required before using it in security-sensitive production environments.
Built With
- cyberchef
- html5
- javascript
- node.js
- webmcp
- webworkers
Log in or sign up for Devpost to join the conversation.