One solution is to encrypt the firmware and keep the decryption keys on the hardware side, preferably in something that’s tamper resistant.
It’s not ideal. It has serious drawbacks. It makes development and updates a PITA. But it does make it much harder to decompile your firmware.
Even so, if you can manage to get a agent into the loop of "change variable > inspect results > do change > repeat", you can replicate everything from server-side game servers to audio effects, as long as you manage to get the data into a format they can either "visually" inspect, or inspect by data. For audio, I've had success replicating synth sounds and effects by giving them MIDI access to analog hardware, spectrograms and a suite of other unix tools.
The tricky part is figuring out the workflow, once that's in place, you can encrypt the protocol itself as much as you want, the output (audio, video, JSON, whatever) has to go somewhere, and that can be captured and replicated.
Or just ask Claude what is the best way to protect your IP. It should know its capabilities.
A lot of the security features on microcontrollers are poorly implemented. Here's an example where someone recovered the encryption key on a consumer device with encrypted firmware: https://garyodernichts.blogspot.com/2024/10/looking-into-nin... . The microcontroller supports firmware encryption with a 128-bit AES key, which gets written to 4 32-bit write-only registers. Because it's split up like this, it's possible to find 1/4 of the key by writing every possible value to one of the registers and checking that the output matches, before repeating with the other 3 registers. This means that the number of possible combinations to check is reduced from (2^128) to (4*(2^32)), which can be brute forced in a few hours.