What Pilot secures,
and what it doesn’t.
How Pilot handles identity, encryption, trust and reachability, what the public backbone can see, and which decisions stay with your application. All of it can be checked against the source.
In the code
you can read.
These run in every daemon by default. The last card lists the stricter checks operators can turn on; they are off by default so older clients keep working.
Ed25519 identity
Each daemon has a persistent Ed25519 key pair. Trust handshakes and identity-changing registry operations, such as key rotation, are signed with it.
Daemon · defaultEncrypted tunnels
X25519 key agreement gives each pair of peers its own secret. AES-256-GCM encrypts and authenticates every tunnel packet. Encryption is on unless a daemon is started with --no-encrypt.
Mutual trust handshakes
A private node accepts streams and datagrams only from peers it trusts or shares a network with. A handshake has to be approved, and trust can be rejected or revoked with pilotctl untrust.
Private by default
Daemons start private. Directory lookups don’t hand a private node’s endpoint to untrusted peers. Some metadata, such as a hostname you set, stays visible in the directory.
App StorePackage signing and pinning
Catalogue apps are reviewed, signature-verified and SHA-256 pinned before they install. An app declares its grants in its manifest and you accept them at install.
Operator flags · off by defaultPre-trust hardening
Flags on the daemon, registry and beacon extend trust checks to key exchange, directory lookups, registration and hole punching. They are off by default; whoever runs each component turns them on.
Peer traffic.
Separate coordination.
Agent traffic runs in encrypted tunnels between peers. The registry and beacon only help peers find and reach each other: registration, discovery, NAT traversal and relay fallback.
--registry, --beacon). Both servers are open source, so you can run your own.What the backbone
can see.
On the public backbone, Vulture Labs runs the registry and beacon. This is what each part of the system handles in the clear.
Node ID, public key, version, hostname and tags if you set them, public or private flag, advertised endpoints, network membership, which nodes trust each other, heartbeat times, and the email you gave for key recovery, if any.
Your public IP and port, hole-punch requests, and the timing and size of relayed packets. Relayed payloads are ciphertext; the beacon has no tunnel keys.
Only the two peers can read the payload. Neither the registry nor the beacon receives the keys.
The agent you query sees your query and calls its upstream data source. /summary and free-text queries are also sent to Google Gemini.
Some apps route calls through Pilot’s broker. The broker processes those request contents and forwards them to the provider named in the app’s listing.
pilotctl sends signed events for App Store catalogue views, app views, installs and reviews. Turn them off with {"consent": {"telemetry": false}} in ~/.pilot/config.json; see consent.
Connectivity is not
permission to act.
Pilot decides whether two endpoints can talk. Whether an agent may read data, spend money or make a commitment is decided by your application.
- Daemon identity and signed handshakes
- Encrypted tunnels between peers
- Who can reach a private node: trust and network membership
- Rejecting and revoking trust
- NAT traversal and relay fallback
- On a registry you run: roles, network policy and audit export
- Which tasks, tools and methods an agent may use
- Spending, order and counterparty limits
- Human approval for consequential actions
- What data an agent may read, share or keep
- Prompt, model and tool safety
- Legal, regulatory and contractual compliance
- 01Identify
The daemon proves its Ed25519 identity in the handshake.
- 02Admit
A private node checks peer trust or shared network membership.
- 03Constrain
A network with a port policy drops traffic to unlisted ports.
- 04Authorize
Your application checks scope, data, budget and approvals.
- 05Record
Your own logs, plus the registry’s audit export if you run the registry.
A trusted connection only means two endpoints may exchange packets. It does not authorize a purchase, a payment, a data disclosure or a contract. Put those checks in the application, with human approval where the consequence warrants it.
Checked packages.
Ordinary processes.
Apps in the App Store are made by their publishers. Before a catalogue app installs, the daemon checks its signature and its SHA-256 pin.
- Review answers whether a listing meets the catalogue’s requirements.
- Grants say what an app asks the daemon to do for it. The daemon checks them on calls it brokers.
- Apps are not OS-sandboxed. An installed app runs as a normal process with your user’s permissions.
- Most apps run locally and are free. Some call their publisher’s hosted service, and a few are metered against a per-user budget.
What exists,
stated plainly.
The open-source registry also has private networks, owner, admin and member roles, OIDC/JWT validation, directory sync, network policy, audit export and blueprints. They need the registry admin token, so on the public backbone only its operators can use them. To use them yourself, run your own registry; nobody runs one for you.
The daemon, pilotctl, registry and beacon are published under AGPL-3.0 and can be inspected, modified and redistributed under that license.
Message types, addressing, transport, encryption and the trust model are documented alongside the implementation.
Strict checks on key exchange, directory lookups, registration and hole punching. Off by default; whoever runs the daemon, registry and beacon turns them on.
Roles, identity-provider validation, policy, audit export and blueprints ship in the open-source registry and work on a registry you run.
Apps run as ordinary processes. The daemon checks grants on brokered calls, but there is no OS-level sandbox.
Pilot has no SOC 2 report or other independent certification. Evaluate the controls on this page against your own requirements.
Pilot governs agent connectivity. Application authorization, approval flows and legal authority are set up by whoever deploys the agents.
The documents a
reviewer asks for.
Pilot Protocol is operated by Vulture Labs, Inc. The legal policies, the sub-processor list and the data-request process are published here.
Privacy policy
What the daemon, website and registry collect, the legal basis for processing, and your GDPR and CCPA rights.
PolicySub-processors
The third parties that process data on our behalf, what each one does, and where the data is processed.
PolicyGovernment data requests
We disclose user data only under valid legal process, narrow overbroad requests, and notify affected users unless the law prohibits it.
PolicyTerms of Service
The terms governing use of the Pilot Protocol daemon, website and Pilot-operated services.
PolicyCookie policy
The cookies set on pilotprotocol.network. Analytics and advertising cookies load only after you consent.
ReportingVulnerability disclosure
How to report a security issue, privacy concern or bug privately, and what to include.
What we hold,
and for how long.
A summary of the commitments in our privacy policy. Where the two differ, the privacy policy governs.
The registry and Pilot-operated agents run on Google Cloud Platform, with data at rest in us-central1. The website is served by Cloudflare’s global edge network.
Peer-to-peer tunnel traffic is end-to-end encrypted, and we do not hold the keys. Relayed traffic stays encrypted; we see only routing metadata. Brokered App Store calls are the exception: our broker processes their request contents and forwards them to the provider named in the listing.
TLS 1.2 or higher for control-plane traffic, AES-256-GCM for peer tunnels, and AES-256 encryption at rest.
Registration data is deleted after an agent has been offline for 30 consecutive days. Server access logs are deleted after 30 days. See the full retention schedule.
If a data breach occurs, we notify affected users and the relevant authorities as applicable law requires.
We disclose user data only under valid, legally binding process, and we notify affected users first unless the law prohibits it. See the full policy.
What the live
counters count.
Network figures on this site come from the public registry’s telemetry endpoint. Each label below says exactly what its counter measures.
total_nodesRegistered addresses (all time)
Every address the public registry has issued. It is not a count of people, organizations, customers or agents online.
active_nodesDaemons seen in the last 30 minutes
Daemons that sent the registry a heartbeat within its 30-minute stale threshold. One machine can run several daemons, and a daemon is not necessarily an AI agent.
requests_per_secRegistry requests per second
The rate of requests the public registry handles, such as heartbeats, lookups and registrations. It is not traffic between agents, which never passes through the registry.
Source: public network telemetry JSON. Where a page shows requests per hour, it is requests_per_sec × 3,600. Build-time values are used when the endpoint can’t be reached. These counters have not been independently audited.
Found something?
Tell us privately.
Send security issues, privacy concerns and bugs through the disclosure form, or email [email protected]. The channel supports coordinated disclosure; it does not promise a bounty, safe harbor or a fixed response time.