PRIVACY POLICY
Secret Tunnel is designed around explicit device capabilities, least privilege, and user-controlled perception. The plugin does not get a universal “read everything” permission.
1. What Secret Tunnel processes
Secret Tunnel processes only information needed for a tool call the user requests and the paired device is authorized to provide.
- Connection and account data: authentication state, paired-device profile labels, and security metadata needed to establish and protect a connection.
- Device telemetry: system resources, power status, hardware inventory, network-interface information, and sanitized radio or environmental observations.
- Personal sensor data: a bounded screen image, camera frame, short microphone sample, or precise location only when the user requests that function and the device owner has separately enabled and granted that sensor.
- Device-defined sensors: non-personal telemetry or environmental channels explicitly advertised under the constrained
perception.device.*namespace.
2. Personal sensors are off by default
Screen, camera, microphone, and precise-location perception require an explicit Sec-TP capability grant and device-owner enablement. Hosted relay mode adds two more controls: the endpoint must deliberately arm the personal sensor for the relay with an absolute lease of no more than 60 minutes and a bounded use count, and the requesting account must hold the sensor-specific OAuth scope. Secret Tunnel cannot silently turn those sensors on.
Precise location is obtained only from the paired device capability. The plugin does not ask users to type GPS coordinates or addresses into tool inputs.
3. How data is used
Data is used to fulfill the requested perception operation, return the result to the requesting ChatGPT or Codex session, authenticate and authorize the connection, protect the service, and diagnose failures. Secret Tunnel does not sell personal data or use sensor data for advertising or behavioral profiling.
4. Who receives data
Requested tool results are provided to the OpenAI product through which the user invoked Secret Tunnel. The hosted relay uses Vercel for application compute and Neon for short-lived relay state; those providers process data only as necessary to deliver the service under their applicable terms. A managed identity provider may process account and authorization data, but Secret Tunnel is designed so that identity infrastructure does not receive sensor payload bodies. We may disclose information when required by law or necessary to protect users and the service. We do not provide sensor data to advertisers or data brokers.
5. Retention
- Hosted sensor relay payloads: a requested observation may be stored temporarily so an outbound-only device and the requesting MCP call can rendezvous. Command and result records become inaccessible after 60 seconds by default, and a result is deleted sooner when the requesting user consumes it. Expired rows are physically deleted opportunistically during relay activity and by a production fallback cleanup job scheduled once per day. On the current Vercel Hobby deployment, an idle expired row may remain as encrypted ciphertext until that daily cleanup runs; it is not returned by Secret Tunnel after its 60-second logical expiry. Sensor-result bodies are encrypted before insertion into the relay database with AES-256-GCM using an application-managed key.
- Application logs: Secret Tunnel is designed not to write sensor payload bodies, device tokens, OAuth access tokens, pairing secrets, or relay encryption keys to application logs. Hosting-provider operational metadata may be retained according to the provider service configuration.
- Hosted device registration: device capability and registration state is refreshed by device check-in and expires after 30 days without refresh by default, unless the user revokes or removes it sooner. Endpoint tokens are stored only as cryptographic hashes.
- Abuse-control state: per-user request-rate counters contain a pseudonymous authorization subject and bounded counters; stale rows are physically deleted after 24 hours.
- On-device pairing and Sec-TP audits: stored on the device or gateway under the device owner’s control and retained until the owner revokes, rotates, or deletes them.
6. Data minimization
Public plugin responses omit authentication secrets, client IDs, certificate fingerprints, request IDs, trace IDs, and timestamps unless they become strictly necessary for a user-requested workflow. Bluetooth observations remove device addresses and names by default. Custom sensor metadata is constrained to prevent a custom channel from becoming arbitrary execution or an undisclosed personal sensor.
7. What Secret Tunnel does not provide
Secret Tunnel does not provide keylogging, credential capture, covert camera or microphone operation, hidden tracking, biometric identification, or an arbitrary remote shell through its public perception interface.
8. User controls
A device owner can disable a personal sensor, let a hosted personal-sensor lease expire, exhaust or remove its relay use budget, remove its Sec-TP capability grant, revoke the paired Secret Tunnel identity, revoke the hosted endpoint registration, remove a device profile, or stop the local gateway. These controls are enforced outside model instructions.
9. Security
Sec-TP uses explicit pairing, certificate pinning, capability authorization, bounded sessions, and audit controls. Hosted mode validates OAuth issuer and audience, uses endpoint tokens stored only as hashes, encrypts transient sensor-result rows with AES-256-GCM, constrains request rates and queue depth, and keeps personal relay sensors disabled unless separately armed at the endpoint. Secret Tunnel is still evolving software, and no security mechanism can guarantee absolute protection. The public service will be operated according to this policy and its published security documentation.
10. Contact
Questions about this policy or Secret Tunnel can be sent to glasscastles@proton.me or through the support page.