AI agent reverse engineering exposes new firmware decryption risk

At a glance

What this is: Bishop Fox tested whether Claude Code could reverse engineer encrypted SonicWall firmware and found it could reconstruct the decryption chain end to end with limited guidance.

Why it matters: This matters because AI-assisted reverse engineering can accelerate both defensive research and adversarial unpacking of protected binaries, which raises the bar for control of secrets, firmware keys, and tool access.

👉 Read Bishop Fox's analysis of AI-assisted SonicWall firmware reverse engineering

Context

AI agent reverse engineering changes the pace of firmware analysis because the limiting factor is no longer only specialist knowledge, but how quickly a model can traverse binaries, key stores, and cryptographic workflows. In this case, the article centres on SonicWall firmware decryption, but the broader governance issue is how agentic tooling interacts with sensitive code, embedded secrets, and reverse-engineering tasks that once required prolonged manual effort.

The identity angle is indirect but real: when reverse-engineering workflows can be delegated to AI agents, the question becomes who or what is allowed to access decompilers, decrypted filesystem images, vault material, and signing keys. That makes agent control, secrets handling, and runtime authorisation part of the same governance conversation, especially where an AI agent is operating as a software entity selecting actions without step-by-step human approval.

The starting position described here is atypical in one sense and now becoming more common in another. Most teams have not yet formalised how AI agents should be supervised in offensive research workflows, even though the tooling and integration patterns are already available.

Key questions

Q: What breaks when AI agents are allowed to inspect sensitive firmware images and decrypted filesystems?

A: The main failure is that an agent can chain together artefacts that humans intended to review separately. Once the model can move from an image to a filesystem to a decompiler, it may reconstruct key paths, secret stores, and recovery workflows faster than expected. The control gap is unscoped tool access, not model intelligence alone.

Q: Why do embedded secrets make firmware encryption much weaker than it appears?

A: Because the image is only protected if the key path stays outside the same trust boundary. When unseal shares, vault data, or service tokens live in the appliance environment, possession of one artefact can unlock the rest. That turns encryption into a delayed disclosure mechanism instead of a durable barrier.

Q: How do security teams know if AI-assisted reverse engineering is becoming a risk in their environment?

A: Look for unmonitored access to decompilers, sandbox images, firmware copies, recovery material, and MCP-connected tooling. If those resources are broadly available, an AI agent can assemble a decryption path or exposure map even when no single source looks dangerous on its own. The signal is tool breadth plus sensitive artefact proximity.

Q: Who should approve the use of AI agents in offensive research workflows?

A: The accountable owner should be the team that controls the sensitive artefacts, the tooling, and the research objective, usually under security or product security governance. AI agents should not operate as implicit analysts. Their use needs a named approver, scoped permissions, and retention rules for any decrypted or reconstructed material.

Technical breakdown

How AI agents traverse firmware containers and decompiled binaries

The workflow begins with the model inspecting the outer container, then moving inward through headers, payload structure, and decompilation output. In this case, the agent recognised an OpenSSL-style encrypted blob, linked it to code paths in a decompiled management binary, and followed the decryption logic until it found the key service backing the firmware process. That pattern matters because agentic analysis is not limited to text summarisation. When an AI system can use tools like a decompiler through MCP, it can pivot between static evidence, runtime clues, and source reconstruction in ways that resemble a seasoned analyst. The practical difference is speed and persistence, not a different class of task.

Practical implication: restrict agent access to binaries, sandboxes, and decompilers through explicit runtime authorisation and monitored tool scopes.

Why embedded vault material changes the threat model

The firmware did not hide its decryption key in one obvious place. Instead, the key path depended on a bundled Vault instance, encrypted data files, and unseal material embedded in the appliance image. That creates a layered trust problem: if an attacker or researcher can obtain a decrypted filesystem, they may be able to recover the key-management boundary that was supposed to protect the firmware. The significance for governance is that secrecy is not just about one key. It is about whether key material, recovery shares, service tokens, and operational binaries live close enough together that a single recovered filesystem collapses the design.

Practical implication: treat appliance filesystems as key-bearing assets and separate recovery material from the binaries they protect.

What OAEP and Shamir reconstruction reveal about agentic cryptanalysis

The article shows an AI agent moving through two non-trivial cryptographic steps: reconstructing a master key from Shamir secret shares and then recovering the correct RSA decryption parameters for the firmware password. Neither step is a generic pattern match. Both require the model to reason about threshold schemes, finite-field arithmetic, and parameter-dependent padding behaviour. This is the point where agentic AI becomes more than a code assistant. It can operate as a cryptanalytic workflow engine, but only if the surrounding environment gives it the right artifacts and enough freedom to iterate. For security teams, the takeaway is that tool access and artifact exposure shape capability more than model size alone.

Practical implication: reduce agent exposure to unsealed secrets, test images, and recovery shares unless that access is explicitly needed and audited.

Threat narrative

Attacker objective: The objective is to decrypt the firmware image and recover the appliance contents, including the key-management logic needed to study or weaponise the platform.

1. Entry begins when an analyst or attacker gains the encrypted firmware image and a decrypted filesystem from the target appliance, giving enough material to reconstruct the decryption path.
2. Credential access and escalation occur when the embedded Vault material, unseal shares, and RSA key path are identified, allowing the protected payload to be unlocked.
3. Impact follows when the decrypted firmware archive is recovered, exposing the appliance contents and the implementation details intended to remain hidden.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted reverse engineering is now a governance problem, not just a research capability. The article shows a model following decryption logic, reconstructing secret material, and completing a firmware analysis chain that previously required a senior human researcher. That means access to decompilers, decrypted filesystem images, and recovery artifacts now needs policy, logging, and approval boundaries. The field should treat these AI workflows as privileged analysis systems, not casual productivity tools.

Embedded recovery material creates a hidden identity and secrets boundary failure. The key lesson is not simply that secrets existed, but that they were close enough to the firmware and runtime environment that one recovered filesystem could collapse the protection model. This is a classic lifecycle failure in a machine-identity context: secret shares, key material, and operational binaries were not sufficiently separated. Practitioners should read this as a warning about collapsed trust zones around appliance-managed credentials.

Agentic tooling amplifies the value of runtime access more than raw model intelligence. The model succeeded because it had the right artifacts and the right tools, not because it magically inferred the answer from ciphertext. That is why MCP-connected tooling, decompilers, and sandboxed binaries deserve the same scrutiny as any other privileged workstation capability. In practice, the governance question is who can bind an AI agent to sensitive tooling and under what supervision.

Firmware protection schemes should be evaluated as environments, not single controls. Encrypting a firmware image does not help if the runtime appliance also contains the key path, the unseal material, and the supporting service logic. This is where security design often fails: control owners assume one layer compensates for another. The practitioner takeaway is to assess how an image, a filesystem, a vault, and an agentic workflow interact as one system.

Model-led analysis will increasingly compress the time between exposure and understanding. That helps defenders, but it also helps attackers who are willing to feed AI agents the same artifacts. The security programme implication is straightforward: if your secrets, images, or recovery shares leak, expect the time to meaningful analysis to shrink. That changes the urgency of containment, not just detection.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• From our research: 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• Forward pivot: For lifecycle and offboarding controls, see NHI Lifecycle Management Guide and the Top 10 NHI Issues for the operational patterns that keep secrets from lingering in exposed environments.

What this signals

Secret-bearing artefacts are now analysable at machine speed when they are exposed to agentic tooling. That means the programme risk is not just theft, but time compression: the interval between exposure and understanding is shrinking. If your environment includes decrypted firmware, sandbox copies, or recovery files, you should assume a model can stitch them together into a usable attack path. For identity teams, the lesson aligns with secrets lifecycle governance, not just incident response.

Artifact separation is becoming the new boundary for AI-enabled research. A model with access to the wrong mix of files can reconstruct paths that no single file reveals. That is a practical reason to tighten handling of decrypted images, recovery material, and privileged tooling under the same governance model used for secrets and service accounts. The adjacent control area is lifecycle discipline, especially where analysis workspaces are reused across projects.

The broader signal is that agentic analysis is moving into the same risk territory as privileged automation. If a workflow can read binaries, query vault material, and iterate through cryptographic dead ends, then it needs the same scrutiny as any other high-risk non-human identity. The operational answer is to classify the workflow, control its toolchain, and monitor its outputs as if it were a privileged service account.

For practitioners

• Constrain AI agent access to reverse-engineering tools Allow decompilers, sandboxes, and MCP-connected analysis tools only inside approved environments with explicit session logging and task scoping. Treat those tools as privileged infrastructure, not general-purpose assistants.
• Separate firmware artefacts from key-bearing material Keep recovery shares, unseal material, and operational binaries in different trust zones so that possession of a decrypted filesystem does not expose the full decryption path.
• Review appliance images for embedded secret dependencies Map every secret-bearing dependency inside firmware and appliance filesystems, including Vault data, service tokens, and unseal workflows, then remove assumptions that shipping code can safely contain recovery paths.
• Apply stricter handling to decrypted test artefacts Assume decrypted filesystem copies and sample firmware images can become stepping stones to key recovery, especially when agents can chain analysis across binaries and configuration files.

Key takeaways

• AI agents can now reproduce advanced reverse-engineering workflows when they are given the right artefacts and tools.
• The deeper risk is not encryption alone, but the proximity of key material, recovery shares, and operational binaries inside one trust boundary.
• Security teams should govern agent access to decompilers, firmware images, and secrets with the same discipline they apply to privileged identities.

Key terms

• Agentic Reverse Engineering: The use of an AI agent to explore binaries, filesystems, and tooling in a goal-driven way. Unlike a simple assistant, the agent can sequence actions, interpret intermediate results, and change approach during analysis, which makes it useful for security research and also risky when exposed to sensitive artefacts.
• Vault Recovery Material: Any secret share, unseal key, token, or internal configuration that can restore access to a key-management system. In practice, recovery material is often more sensitive than the protected asset itself because it can collapse the control boundary that encryption was meant to preserve.
• Firmware Decryption Path: The chain of files, keys, parameters, and runtime logic required to unlock a protected firmware image. Security teams should treat the path as an asset in its own right, because exposure of the path can be as damaging as exposure of the image content.

What's in the full article

Bishop Fox's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step decompilation of the SonicWall management binary and the exact path used to locate the Vault-backed key logic.
• The full cryptographic reconstruction sequence, including the Shamir share handling and OAEP hash debugging that led to decryption.
• The redacted code excerpts and command flow used to run the original Vault binary and export the RSA key.
• Bishop Fox's own reasoning notes on where the model stalled and how human supervision changed the result.

👉 Bishop Fox's full post covers the decryption chain, cryptographic dead ends, and redacted technical details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security workflows that now include agentic tooling and privileged automation.