Let the model write the CyberChef recipe, let deterministic code do the decode

A dev.to write-up on CyberChef for red and blue teams makes one argument worth extracting from the tooling detail: in AI-assisted security work, the model should propose or interpret the recipe while CyberChef performs the actual decode or transform ^[2]. The author's reasoning is that this is safer and more reproducible than asking an LLM to mentally decode a long blob and then trusting the answer ^[3], and that the deciding property is that the transformation engine is deterministic code ^[2].

The practical value shows up in the shape of real SOC data. Nested transformations are common: URL encoding to Base64 to gzip to JSON, or hex to bytes to embedded strings, and CyberChef lets an analyst build a visible recipe and preserve it with the case ^[13]. That is the part an LLM cannot supply. A model is good at recognising a likely encoding and proposing a sequence ^[20]; it is not an artifact you can rerun six months later in front of a reviewer. The recipe is. GCHQ's CyberChef chains operations for encoding and decoding, hashes and checksums, compression, binary and hexdumps, character encodings and certificate or data parsing ^[1], and it runs locally in the browser, which matters for sensitive evidence ^[19]. There is also a Node API for programmatic recipes once you build the Node package ^[11], which is where the planner-executor split stops being a habit and becomes pipeline code.

The discipline around it is unglamorous and load-bearing. Work on an extracted artifact, such as a registry value, an encoded PowerShell fragment, a log field or a carved blob, while preserving the original evidence and its hash; the tool does not replace evidence acquisition or chain-of-custody controls ^[15]. Do not execute decoded content, transform it as data, and if the output turns out to be a script or a binary, move to a malware-analysis workflow rather than running it from the analyst desktop ^[14]. Scope and authorisation rules apply exactly as they do to any other tooling, and the recipe system is not a justification for generating payloads against out-of-scope targets ^[17].

Know the edges. CyberChef is not a malware sandbox, packet analyser or forensics suite; it is a transformation layer over data extracted from those ^[12]. The post's routing is sensible: Wireshark or tshark for network capture, Volatility for memory forensics, Caido for web request interception, CloudFox for cloud attack paths ^[18]. And CyberChef's own security policy cautions that its cryptographic operations should not be relied on as a security guarantee, with production cryptography left to established libraries, HSMs or KMS implementations ^[4].

Deployment specifics, as stated in the article: CyberChef is not a standard Kali package in the sources it verified, so use upstream ^[5]. Getting-started documentation, updated April 2026 per the post, requires Node.js 24 for the development build ^[6]; the flow is git, Node 24, clone gchq/CyberChef, npm install, npm start ^[7], with the development server documented at localhost:8080 ^[8] and npm run build writing production files under build/prod/ ^[9].

What to watch: the post says the project shipped security fixes in 2026 and advises pinning a reviewed release rather than tracking master ^[10]. If your team adopts the planner-executor split, the thing to check in a quarter is whether the recipe and the artifact hash are actually stored together in case notes ^[13][15], or whether the model's prose summary is still what gets pasted into the ticket.