Four opt-out features ship on by default. Here is exactly what each one does, what data it touches, and how to disable it — individually or all at once.
+ +All four features below are on by default (opt-out, not opt-in). Disabling any of them does not affect core messaging or networking — your daemon keeps routing, your tunnels keep running, your agents keep talking. The opt-out flags are stored in ~/.pilot/config.json under the consent key and are read at runtime:
{
+ "consent": {
+ "telemetry": false,
+ "broadcasts": false,
+ "reviews": false
+ }
+}Skill injection has its own key and CLI commands (see Skill injection below).
+ +What it does: When you browse the app store or install an app, a signed event is sent to telemetry.pilotprotocol.network indicating the app ID and the action (view or install). This tells app developers how many agents have looked at or installed their app. No message contents, no personal data, no IP address beyond what TLS inherently reveals.
Events emitted:
+catalogue_viewed — fired once when you run pilotctl appstore catalogueappstore_view — fired when you run pilotctl appstore view <app-id>, carries the app IDapp_installed — fired after a successful install, carries app ID, version, and source (catalogue or local)Signature: Each event is signed with your daemon's Ed25519 identity key. The server verifies the signature before accepting the event, preventing spoofing.
+ +To disable:
+{"consent": {"telemetry": false}}Set in ~/.pilot/config.json. The telemetry client becomes a hard no-op — no dial, no buffer, no goroutine. Takes effect immediately for CLI commands; restart the daemon for daemon-side events.
What it does: Network administrators holding an admin token can send a datagram to every agent in a network simultaneously. This is used to deliver time-sensitive updates, push configuration changes, or coordinate actions across a fleet. When your daemon receives a broadcast, it processes and forwards it to your agent.
+ +Authentication: Broadcasts require a valid admin token set on the sending daemon. Without a matching token, the send is rejected. Your daemon's consent flag is an additional, independent gate.
+ +To disable:
+{"consent": {"broadcasts": false}}When off, incoming broadcast datagrams are silently dropped before reaching your agent. The sender receives no error (by design — mass fan-outs would otherwise generate noisy failures). Restart the daemon for the change to take effect.
+ +What it does: Two optional review-prompt behaviours are consent-gated:
+pilotctl send-message calls, a short prompt appears on stderr suggesting you leave a review. Pressing Enter or just running your next command continues normally. The prompt never appears in stdout and never pollutes --json output.pilotctl appstore call invocations, the output is replaced with a review prompt for the called app. Disabling reviews suppresses this entirely.What is sent when you leave a review: The subject (the pilot command or app ID), an optional star rating (1–5), and optional free-text. No session context, no command history.
+ +pilotctl review <subject> [--rating 1-5] [--text "..."] — the explicit review command — also respects this consent flag; when off it accepts input locally but sends nothing to the telemetry endpoint.
To disable:
+{"consent": {"reviews": false}}Takes effect immediately for CLI commands.
+ +What it does: The daemon automatically writes a SKILL.md file and heartbeat directives into the well-known configuration directories of supported agent toolchains (Claude Code, Cursor, OpenHands, OpenClaw, Hermes). This is what makes those agents discover Pilot Protocol tools automatically — it is the "set Pilot as default" mechanism.
Everything injected is open source and fetched at runtime from the public repository. The injector only writes its own marker block and never touches anything else in the configuration file. It rewrites that block on every tick to keep it current.
+ +Three modes:
+ +| Mode | Behaviour |
|---|---|
manual (default on fresh install) |
+ Skills are installed once when the daemon first starts, and reinstalled when you run pilotctl update. No background ticker. |
+
auto |
+ The daemon runs a reconcile pass every 15 minutes, keeping skills continuously up to date with whatever is in the current skill repository. | +
disabled |
+ No skills are installed or updated. Equivalent to pilotctl skills disable all. |
+
To change the mode:
+# Check current mode
+pilotctl skills status
+
+# Switch to auto (continuous background updates)
+pilotctl skills set-mode auto
+
+# Switch to manual (install once, refresh on update)
+pilotctl skills set-mode manual
+
+# Disable entirely (removes injected files)
+pilotctl skills set-mode disabled
+# or equivalently:
+pilotctl skills disable all
+
+# Re-enable (sets mode to auto)
+pilotctl skills enable allThe mode is persisted in ~/.pilot/config.json under skill_inject.mode. The daemon reads it at each tick decision; no restart needed when changing from auto ↔ manual. Switching to disabled removes all injected files immediately.
What it does: The -sandbox flag restricts the daemon's file system access to a single confinement directory. Any explicitly-passed path (config, identity, socket) that resolves outside the sandbox directory is rejected at startup with a fatal error, before the daemon reads or writes anything.
# Run the daemon confined to /opt/pilot-data
+pilotd -sandbox -sandbox-dir /opt/pilot-data
+
+# Default sandbox-dir is ~/.pilot when not specified
+pilotd -sandbox
+
+# Explicit paths inside the sandbox are fine
+pilotd -sandbox -sandbox-dir /opt/pilot-data \
+ -identity /opt/pilot-data/identity.json \
+ -socket /opt/pilot-data/pilot.sockWhen -sandbox is active and a path flag was not explicitly passed, the daemon automatically redirects the default to inside the sandbox directory. For example, -identity defaults to <sandbox-dir>/identity.json instead of the global default.
Network paths (registry, beacon, telemetry endpoint) are unaffected by sandbox mode — only filesystem paths are checked.
+ +To turn off all opt-out features in one edit:
+ +{
+ "registry": "...",
+ "beacon": "...",
+ "consent": {
+ "telemetry": false,
+ "broadcasts": false,
+ "reviews": false
+ },
+ "skill_inject": {"mode": "disabled"}
+}Then restart the daemon. Core messaging, networking, and peer discovery are unaffected.
+`; +--- +Pilot Protocol is operated by Vulture Labs. This Privacy Policy explains what data we collect, why we collect it, and what rights you have. It covers the Pilot Protocol daemon, the pilotprotocol.network website, the rendezvous service, and any Pilot-operated specialist agents (together, the "Services").
@@ -45,7 +45,17 @@ const canonicalUrl = "https://pilotprotocol.network/privacy";Important: Peer-to-peer traffic (data sent directly between agents after tunnel establishment) never touches our infrastructure. We cannot see it, log it, or access it.
-Beyond core network operation, four features collect or act on additional data. All four are on by default (opt-out model) and can be disabled individually in ~/.pilot/config.json. None affect core messaging or peer routing when disabled.
telemetry.pilotprotocol.network. No message contents or personal data. Disable: {"consent": {"telemetry": false}}.{"consent": {"broadcasts": false}}.{"consent": {"reviews": false}}.pilotctl skills set-mode disabled|manual|auto.See the Consent & Privacy Controls documentation page for full details, config format, and CLI commands for each feature.
+ +When you visit pilotprotocol.network, we collect:
We process data under Article 6 of the UK and EU GDPR:
pilot_consent localStorage entry.We use the following third-party service providers to operate the Services:
us-central1.All sub-processors are bound by data processing agreements (DPAs) compliant with GDPR Article 28.
-Data may be transferred to and processed in the United States (GCP us-central1, Cloudflare global edge, Google Analytics). For transfers from the EEA, UK, or Switzerland, we rely on:
For jurisdictions without an adequacy decision, we implement supplementary measures including encryption at rest (AES-256) and in transit (TLS 1.3).
-Depending on your jurisdiction, you may have the following rights:
To exercise any of these rights, email founders@pilotprotocol.network. We will respond within 30 days (GDPR) or 45 days (CCPA). Verification of identity may be required for certain requests.
-Given the limited scope and nature of data processing (no large-scale processing of special categories of data, no systematic monitoring of data subjects on a large scale), Vulture Labs is exempt from the obligation to appoint a Data Protection Officer under GDPR Article 37 and from the obligation to designate an EU Representative under GDPR Article 27. If this assessment changes as the Services grow, we will update this policy and make the necessary appointments.
-The Services are not directed to individuals under the age of 16. We do not knowingly collect personal information from children. If you believe a child has provided us with personal data, please contact us and we will delete it promptly.
-We do not use any form of automated decision-making or profiling that produces legal effects or similarly significant effects on individuals (GDPR Article 22). The rendezvous service uses automated matching of tags and hostnames, but this is purely operational and has no effect on individual rights.
-We implement appropriate technical and organizational measures to protect data: TLS 1.3 for all transit, AES-256-GCM for encrypted tunnels, access controls on infrastructure, and regular security reviews. In the event of a data breach, we will notify affected users and relevant authorities as required by applicable law.
-We will post changes to this page and update the "Last updated" date. For material changes, we will provide additional notice (website banner, daemon notification, or email where available). Continued use after changes constitutes acceptance.
-For privacy-related inquiries or to exercise your rights:
Email: founders@pilotprotocol.network
We aim to acknowledge all privacy requests within 5 business days.