> For the complete documentation index, see [llms.txt](https://docs.slinky.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.slinky.network/privacy/threat-model.md).

# Threat model

### Protect intent, authority, value, and integrity

The highest-value asset is not only the prompt. The system must also protect tool-selection logic, unpublished research, wallet authority, spending policy, vendor credentials, response provenance, configuration, and the evidence that binds a result to a paid operation.

<figure><img src="/files/MnVtYNSXOxdugDLYV8Xl" alt=""><figcaption></figcaption></figure>

### Assume partial compromise and hostile inputs

Relevant adversaries include a passive network observer, a malicious or compromised provider, an abusive client, a compromised browser, a poisoned web page, a leaked vendor credential, and an operator with excessive production access. The architecture does not assume every external system colludes, but it avoids giving one system enough data by default.

### Primary risks and required controls

| THREAT                                  | CONTROL                                                                                    | RESIDUAL RISK                                                               |
| --------------------------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
| Cross-request identity correlation      | Accountless access, Tor route, identifier stripping, wallet separation guidance            | Unique task text and reused payment addresses can remain linkable           |
| Prompt leakage through logs             | Allowlisted telemetry schema, body redaction, log tests, restricted debug workflow         | Application crashes or third-party middleware can capture unexpected fields |
| Duplicate charge on retry               | Idempotency keys, canonical request hashes, settlement reconciliation                      | Client crash between settlement and local receipt persistence               |
| Prompt injection from retrieved content | Treat sources as data, isolate instructions, tool allowlists, action approval boundary     | A model can still misclassify adversarial content                           |
| Provider credential theft               | Server-side secret manager, scoped keys, egress controls, rotation, usage alerts           | Provider-side compromise remains outside direct control                     |
| Wallet drain through malicious quote    | Destination allowlist, per-call cap, network and asset checks, simulation where applicable | User can explicitly approve a harmful transaction                           |
| Direct-route privacy bypass             | Fail-closed Tor policy, egress verification, route health monitoring                       | Timing and volume analysis may still be possible                            |
| Result tampering                        | TLS, schema validation, source metadata, response hashes, signed receipts where available  | Source publishers can change or remove evidence later                       |

### Communicate what controls cannot remove

Residual risk belongs in product decisions, not only in a security appendix. Clients should warn when a task contains a public wallet address, requests an identifiable personal record, requires a provider with weaker retention terms, or leads to a public transaction.

Risk acceptance must be specific to a route and capability. A broad privacy label cannot replace a tested data flow, a published retention period, or an explicit action confirmation.