Tor and network privacy
Calling an external model or data provider can reveal more than the question being asked. The provider may also receive an IP address, approximate location, request timing and other network metadata.
SlinkyLayer places a Tor route between its private interface and downstream tools. The selected provider receives the request from the Tor network rather than through a direct connection associated with the user.
What happens to a tool request
Before a request leaves SlinkyLayer, two separate protections are applied:
Context routing prepares a smaller request containing only the information needed by the selected tool.
Tor routing sends that request through the Tor network before it reaches the provider.
These protections solve different problems. Context routing limits the data being shared. Tor routing reduces exposure of the request's network origin.
A market-data provider, for example, may receive an asset symbol and time range. It should not receive the user's unrelated conversation history, direct IP address or other tasks discussed during the same session.
What Tor protects
Tor is used to reduce the network information visible to downstream models and tools.
Direct user IP address
Not shared through the Tor-routed tool request
Network origin
Obscured by the Tor route
Scoped task
Visible because the tool needs it to perform the work
Full conversation
Not included by default
Unrelated identity details
Excluded unless required by the task
Public wallet activity
May remain visible onchain
The provider can still observe that a request arrived from the Tor network. It can also read the task it has been asked to complete.
Tor protects the route taken by a request. It does not make the request content invisible to the tool processing it.
Privacy has more than one boundary
Network privacy is only one part of the system. A request can be Tor-routed and still contain identifying information if the user includes it in the task.
For example, a research tool will receive a person's name if the user asks it to investigate that person. A blockchain tool will receive a wallet address if the task concerns that wallet.
SlinkyLayer reduces unnecessary disclosure, but it cannot remove information that is essential to the requested work.
Payments and blockchain activity
x402 payments and other blockchain actions have different privacy properties from Tor-routed tool requests.
Tor can prevent a provider from receiving the user's direct network origin. It does not remove information recorded on a public blockchain. Wallet addresses, payments, transactions and protocol interactions may remain publicly observable after settlement.
Users and agents should treat a public wallet as a persistent identifier. Spending limits, wallet separation and approval policies should be considered independently of Tor routing.
The scope of this protection
The Tor protection described here applies to outbound requests sent from SlinkyLayer to downstream tools. It should not be interpreted as a guarantee that every part of the user's internet connection, device or blockchain activity is anonymous.
For better privacy:
Avoid including personal information unless the task requires it.
Review the scoped request before approving sensitive operations.
Treat wallet addresses and public transactions as observable.
Check the selected tool's retention terms.
Require explicit approval before payments or onchain actions.
SlinkyLayer combines Tor routing with context minimization because neither protection is sufficient on its own. The aim is straightforward: give each tool the information it needs while exposing as little else as possible.
Last updated