Threat model
Stated plainly — what ArxCode defends against, and what it does not.
We state explicitly what ArxCode defends against and what it assumes. The adversary may be the host, a network observer, a legal authority compelling disclosure, or a future owner with changed incentives. Their goal is to read, copy, or train on your input.
What ArxCode defends against
| Adversary | Defense |
|---|---|
| Host & infrastructure | Input is decrypted only inside the sealed boundary — there is no accessible plaintext outside it. |
| Network observer | Inputs and outputs travel encrypted to wallet-bound keys — an observer sees ciphertext and timing, not content. |
| Subpoena & breach | Nothing is retained after a build. There is no store to compel and no log to exfiltrate. |
| Drift | Because retention is foreclosed by architecture, a future policy change can't reach data that was never collected. |
What it does not defend against
We are honest about the limits. ArxCode does not protect against:
- A user who voluntarily discloses their own output.
- Endpoint compromise on the user's own device (a keylogger, malware, a stolen wallet key).
Privacy is architectural, not contractual
The protections above hold because the architecture makes surveillance impossible — not because ArxCode promises restraint. There is no retained corpus, no log, and no admin session to compromise.
Next
- See the full guarantee in Sealed execution.
- Read the privacy argument in Privacy as protocol.