Threat model

Assets, adversaries, abuse cases, mitigations, and residual risks for the Slinky request path.

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.

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.