The prompts are the product. Not the code — the code is a tool-use loop anyone could write in an afternoon. And the product ships as a container running inside infrastructure the customer controls completely. That tension has one real answer, one regression I caused myself, and a tradeoff that works directly against the sales conversation.
What is actually valuable here
Worth being precise, because it determines what needs protecting.
The orchestration code is not valuable. It is a thin loop, and a competent engineer reproduces it from a description. The query builders have accumulated real knowledge but that knowledge is discoverable by anyone willing to spend months with the same telemetry.
The prompts are different. The supervisor's methodology, the nine specialist knowledge scopes, the rules about what a null result means and when to ask a human — that is the distilled output of the entire project, and it is plain text. Reading it once tells you most of what was learned. It is simultaneously the most valuable artefact and the most trivially copyable one.
Three layers, honestly rated
| Layer | Mechanism | What it actually stops |
|---|---|---|
| 1 | Compiled binary, no source shipped | Casual reading. Not disassembly. |
| 2 | No prompt strings in the image | The strings command, which is the realistic attack |
| 3 | Runtime delivery, never at rest | Anyone who is not intercepting live process memory |
Layer three is the only one doing significant work. The agent fetches its prompt bundle from a licensing service at startup, holds it in memory, and never writes it to disk. Pull the image apart and the prompts are not in it — not obfuscated, not encrypted, absent.
Layers one and two are deterrence. String literals are extractable from any compiled binary with a single command, so a build that embeds prompts is a build that ships them regardless of language. That was the June assessment's central point about Go versus obfuscated Python and it remains true: the language choice barely moves this needle. The delivery model does.
The regression I caused
Having designed runtime delivery carefully, I then shipped a container image with the prompts inside it.
The mechanism was mundane. The prompt files lived in the repository for local development convenience, with the build configured to exclude them from the image. A change to the build context stopped the exclusion applying. Nothing failed. Nothing warned. The image built, ran, and worked perfectly — using the prompts it should not have contained.
The fix was not a better exclusion rule. It was removing the prompts from the repository entirely, so that local development requires a live connection to the bootstrap service with no disk fallback. Development is now slightly more annoying, permanently, and the class of bug is gone rather than patched.
The companion control is a periodic audit that no prompt text reaches any log line, debug output, or audit record. Those records are written into the customer's own workspace, so a leak there would place the prompts in exactly the environment the whole design is meant to keep them out of.
The adversary model, stated plainly
Against a motivated reverse engineer with access to the running host, none of this works. They can attach to the process, dump memory, and read the prompts. That is not a solvable problem for software running on someone else's infrastructure, and anyone claiming otherwise is selling something.
The realistic adversary is not that person. It is a curious administrator who pulls the image apart out of professional interest, or a competitor's engineer doing the same with commercial intent. Both are stopped by prompts that are not in the image, and both are cheap to stop. Defending against the theoretical maximum adversary would cost far more and deliver nothing additional against the realistic one.
The tradeoff that is not resolved
Every control here makes the container more opaque, and opacity is precisely what a security buyer is objecting to when they ask what this thing does with their telemetry. Layer two of the trust problem is made structurally harder by the thing that protects layer one of the business.
I do not think this fully resolves. The partial answer is to be transparent about everything except the prompts: publish the permission list with per-permission justification, publish the exact egress endpoints and what transits each, and tell the prospect how to watch the container's outbound connections from their own side. Full behavioural transparency, with the reasoning content held back.
That is a coherent position and it is not as strong as being open. A buyer who wants to read the prompts before trusting the verdicts is asking for something reasonable that I am declining to give them. The honest framing is that this is a cost of the business model, not a security feature, and it should be named as one.