From 76b6b3cbc50511f1af74b3f99156bd7b861ee4df Mon Sep 17 00:00:00 2001 From: pstayets Date: Fri, 14 Aug 2026 21:16:45 -0700 Subject: [PATCH 1/4] =?UTF-8?q?blog:=20AES-256-GCM=20Encryption=20?= =?UTF-8?q?=E2=80=94=20expand=20zero-dependency=20post=20for=20GSC=20strik?= =?UTF-8?q?ing-distance=20query?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: pstayets --- src/data/blogPosts.json | 4 +-- ...dependency-encryption-x25519-aes-gcm.astro | 28 +++++++++++++------ 2 files changed, 22 insertions(+), 10 deletions(-) diff --git a/src/data/blogPosts.json b/src/data/blogPosts.json index c853794..df4503b 100644 --- a/src/data/blogPosts.json +++ b/src/data/blogPosts.json @@ -1269,8 +1269,8 @@ }, { "slug": "zero-dependency-encryption-x25519-aes-gcm", - "title": "Zero-Dependency Agent Encryption: X25519 + AES-256-GCM in Pure Go", - "description": "How Pilot implements authenticated key exchange, tunnel encryption, nonce management, and replay protection using only Go's standard library.", + "title": "AES-256-GCM Encryption: Zero-Dependency Go Implementation Guide", + "description": "AES-256-GCM encryption explained with code: X25519 key exchange, GCM authenticated encryption, nonce handling, and wire format in zero-dependency Go.", "date": "Feb 8", "category": "Security", "tags": [ diff --git a/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro b/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro index d55007e..9af59e0 100644 --- a/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro +++ b/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro @@ -1,7 +1,7 @@ --- import BlogLayout from '../../layouts/BlogLayout.astro'; -const bodyContent = `

Pilot Protocol implements its entire encryption stack -- X25519 key exchange plus AES-256-GCM authenticated encryption -- using nothing but Go's standard library. No OpenSSL, no libsodium, no third-party crypto module. This article shows exactly how that implementation works: the key exchange code, the wire format, nonce handling, and the security properties you get as a result.

+const bodyContent = `

AES-256-GCM encryption is the authenticated-encryption mode that protects every message in transit on Pilot Protocol -- implemented, together with X25519 key exchange, using nothing but Go's standard library. No OpenSSL, no libsodium, no third-party crypto module. This article shows exactly how that AES-256-GCM encryption works end to end: the key exchange code, the wire format, nonce handling, and the security properties you get as a result.

Every encryption library is a dependency. Every dependency is an attack surface. When OpenSSL disclosed Heartbleed in 2014, it affected a large share of TLS servers on the internet -- not because of a flaw in the cryptographic algorithms, but because of a buffer over-read in a library that virtually every project imported without auditing. The xz Utils backdoor in 2024 demonstrated that even compression libraries can become supply chain weapons when a determined attacker gains commit access.

@@ -25,11 +25,11 @@ const bodyContent = `

Pilot Protocol implements its entire encryption stack --

External crypto libraries often pull in hundreds of thousands of lines of code. OpenSSL alone is over 500,000 lines of C. Auditing this is a multi-year, multi-million-dollar effort that most organizations never complete.

-

Pilot's encryption relies only on Go's standard-library crypto/ecdh, crypto/aes, crypto/cipher, and crypto/sha256 — a few thousand lines of well-documented, type-safe, widely-reviewed Go, with no third-party cryptography dependencies to audit.

+

Pilot's encryption relies only on Go's standard-library crypto/ecdh, crypto/aes, crypto/cipher, and crypto/sha256. That keeps third-party cryptography modules out of Pilot's dependency graph and makes the relevant implementation available in the Go source tree.

Reproducible Builds

-

With zero external dependencies, the encryption code is fully determined by the Go version. Every developer, CI system, and deployment pipeline that uses the same Go version produces identical binaries. There is no version skew, no dependency resolution ambiguity, and no risk of pulling a compromised version from a package registry.

+

Using the standard library ties the cryptographic implementation to the selected Go toolchain instead of a separate module graph. Reproducible binaries still require the build environment, flags, source revision, and toolchain to be controlled, but there is no additional cryptography package version to resolve.

Practical impact: Pilot’s components compile to static binaries with no dynamic runtime dependencies. The standard installer places the daemon, CLI, and updater for supported Linux and macOS targets in one command; see Compatibility for the current platform matrix.

@@ -84,9 +84,13 @@ Agent A Agent B

The X25519 computation itself is sub-millisecond; the dominant setup cost is the one network round-trip for the handshake, which is bounded by the peers' RTT. The crypto cost is paid once per tunnel, not per packet.

-

AES-256-GCM: Authenticated Encryption

+

AES-256-GCM Encryption: How the Mode Works

-

After key exchange, all tunnel frames are encrypted with AES-256-GCM (RFC 5288). GCM (Galois/Counter Mode) is an authenticated encryption mode that provides both confidentiality (the data is encrypted) and integrity (any modification is detected). It is the same cipher suite used by TLS 1.3 for HTTPS traffic worldwide.

+

After key exchange, all tunnel frames are encrypted with AES-256-GCM. GCM (Galois/Counter Mode) is an authenticated encryption mode that provides both confidentiality (the data is encrypted) and integrity (modification is detected). AES-GCM is also among the authenticated-encryption modes supported by TLS 1.3.

+ +

GCM is built from two operations. The first is AES in counter mode (CTR): the block cipher encrypts an incrementing counter, and the resulting keystream is XORed with the plaintext. That is how a block cipher encrypts arbitrary-length data. The second is GHASH, a universal hash function computed over the ciphertext that produces the authentication tag. Because the tag is a function of the ciphertext, an attacker who flips a single bit in transit must also forge a valid tag for the modified message. Without the key, that forgery is detected and the packet is rejected before any plaintext is released. This is what makes GCM "authenticated": confidentiality and integrity arrive in one pass, with one key, from one Seal call.

+ +

The construction also explains the two invariants an implementation must enforce. First, a nonce must never be reused under the same key -- the counter mode makes the keystream identical for identical nonces, which is why Pilot uses the two-part nonce construction described below. Second, the authentication tag must be verified before the plaintext is trusted. Pilot is responsible for nonce uniqueness; Go's Open function verifies the tag and returns an error instead of unauthenticated plaintext when verification fails.

Encryption in Go

@@ -313,7 +317,7 @@ const faqItems = [ }, { question: "Why use AES-256-GCM instead of AES-CBC or another mode?", - answer: "AES-256-GCM is an authenticated encryption mode, so it provides confidentiality and integrity in one pass -- any tampering with a packet is detected and the packet is discarded. It is the same cipher suite TLS 1.3 uses for HTTPS traffic, and Go's crypto/cipher implementation includes AES-NI hardware acceleration.", + answer: "AES-256-GCM is an authenticated encryption mode, so it provides confidentiality and integrity in one pass -- tampering is detected and the packet is discarded. AES-GCM is also supported by TLS 1.3, and Go's AES implementation can use hardware acceleration on supported processors.", }, { question: "How does Pilot Protocol prevent nonce reuse in AES-GCM?", @@ -323,11 +327,19 @@ const faqItems = [ question: "Why not just use TLS for AI agent encryption?", answer: "Standard TLS runs over TCP and commonly depends on X.509 certificate issuance and revocation. Pilot Protocol runs over UDP and derives tunnel secrets with X25519 without requiring X.509 at this layer, avoiding that certificate lifecycle and the larger dependency surface that crypto/tls brings in.", }, + { + question: "What is AES-256-GCM encryption?", + answer: "AES-256-GCM is the Galois/Counter Mode of the AES block cipher with a 256-bit key. It is an authenticated encryption mode: AES in counter mode encrypts the data, while the authentication tag lets the receiver detect modification. AES-GCM is supported by TLS 1.3 and is the mode Pilot uses for tunnel payload encryption.", + }, + { + question: "AES-256-GCM vs ChaCha20-Poly1305: which should you use?", + answer: "Both are authenticated encryption schemes with the same security goals. AES-256-GCM benefits from AES hardware acceleration on supported processors and is Pilot's current tunnel mode. ChaCha20-Poly1305 is a strong alternative with consistent software performance and is used by WireGuard. The practical choice depends on the protocol, implementation, and deployment hardware.", + }, ]; --- Date: Sun, 16 Aug 2026 17:57:44 -0700 Subject: [PATCH 2/4] =?UTF-8?q?optimize:=20/app-store=20=E2=80=94=20query-?= =?UTF-8?q?forward=20title/meta,=20agent-app=20intro,=20interlinks,=20llms?= =?UTF-8?q?.txt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: pstayets --- public/llms.txt | 1 + src/pages/app-store.astro | 7 ++++--- src/pages/blog/build-agent-app-turn-api-into-tool.astro | 2 +- src/pages/blog/how-pilot-protocol-works.astro | 2 +- src/pages/plain/app-store.astro | 6 ++++-- 5 files changed, 11 insertions(+), 7 deletions(-) diff --git a/public/llms.txt b/public/llms.txt index 48b52c0..8a01542 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -36,6 +36,7 @@ The managed control plane is in preview. Supported adapters can surface agent ac ## Docs +- [App Store](https://pilotprotocol.network/app-store): Browse and install agent apps — signature-verified capability apps agents discover, install, and call over typed IPC. - [Trust Center](https://pilotprotocol.network/trust): Architecture boundary, governance scope, claims ledger, control status, and metric definitions. - [Security](https://pilotprotocol.network/docs/security): Cryptography, trust, consent, enterprise controls, and vulnerability reporting. - [Getting Started](https://pilotprotocol.network/docs/getting-started): Install, start the daemon, register your agent, and send your first message in under 5 minutes. diff --git a/src/pages/app-store.astro b/src/pages/app-store.astro index 50fbc5c..618d79a 100644 --- a/src/pages/app-store.astro +++ b/src/pages/app-store.astro @@ -11,8 +11,8 @@ import { osSummary } from '../data/format'; import '../styles/system.css'; import '../styles/appstore.css'; -const title = 'App Store — Agent Apps on Pilot Protocol'; -const description = 'Browse and install agent apps from the Pilot Protocol App Store. Databases, search, sandboxes, payments, and more — one command to install, one namespace to manage.'; +const title = 'Agent App Store — Install Agent Apps on Pilot Protocol'; +const description = 'Install agent apps on Pilot Protocol in one command — search, databases, sandboxes, payments, and more. Discover, install, and call as typed JSON services.'; const canonicalUrl = 'https://pilotprotocol.network/app-store'; const featured = featuredApps(); @@ -72,6 +72,7 @@ const publishHref = '/publish';
App Store

Agent apps.
One command away.

Experiences built for agents, not browsers. Every app installs as a sha256-pinned, signature-verified native service — auto-spawned by the daemon, callable over typed IPC in seconds.

+

An agent app is an installable capability — a database, a search backend, a sandbox, a payment rail — packaged as a typed JSON-in/JSON-out service that runs locally on your daemon. The loop is discover → install → call: browse the catalogue, install with one command, and call the app's methods from any agent on the network. New to the model? Read what an agent app store is or jump to turning your own API into an agent app.

{apps.length}
Apps
{categories.length}
Categories
@@ -182,7 +183,7 @@ const publishHref = '/publish';
For builders

Ship an agent app.
It’s just a manifest.

-

Describe your app's methods in a guided submission — we build, sign, and review the adapter. Once approved, pilotctl appstore install <id> works everywhere on the overlay.

+

Describe your app's methods in a guided submission — we build, sign, and review the adapter. Once approved, pilotctl appstore install <id> works everywhere on the overlay. Wondering how agent apps fit next to MCP tools? See MCP + Pilot: tools and a network for AI agents.

Publish your app → diff --git a/src/pages/blog/build-agent-app-turn-api-into-tool.astro b/src/pages/blog/build-agent-app-turn-api-into-tool.astro index 896c3c2..ce01c86 100644 --- a/src/pages/blog/build-agent-app-turn-api-into-tool.astro +++ b/src/pages/blog/build-agent-app-turn-api-into-tool.astro @@ -79,7 +79,7 @@ const bodyContent = `

You have an API. It has a REST endpoint, maybe a Python

Why publish at all

-

The store grows by builders adding to it. Every published app becomes one more capability agents on the network can install with one command, without a framework-specific SDK for every harness. If an API is useful to autonomous agents, publishing it once makes the same adapter discoverable across supported environments.

+

The store grows by builders adding to it — browse the live catalogue at the Pilot Protocol app store. Every published app becomes one more capability agents on the network can install with one command, without a framework-specific SDK for every harness. If an API is useful to autonomous agents, publishing it once makes the same adapter discoverable across supported environments.

diff --git a/src/pages/blog/how-pilot-protocol-works.astro b/src/pages/blog/how-pilot-protocol-works.astro index ed4e069..6835028 100644 --- a/src/pages/blog/how-pilot-protocol-works.astro +++ b/src/pages/blog/how-pilot-protocol-works.astro @@ -283,7 +283,7 @@ const bodyContent = `

How Pilot Protocol works: it is a UDP o -

The port system means agents can expose multiple services simultaneously. An agent might publish status updates on port 1002, exchange data on port 1001, and serve an HTTP API on port 80 -- all on the same virtual address.

+

The port system means agents can expose multiple services simultaneously. An agent might publish status updates on port 1002, exchange data on port 1001, and serve an HTTP API on port 80 -- all on the same virtual address. Beyond these built-in ports, agents can also extend their daemon with installable capability apps from the Pilot Protocol app store — signature-verified, typed JSON-in/JSON-out services auto-spawned on install.

HTTP Over Pilot

diff --git a/src/pages/plain/app-store.astro b/src/pages/plain/app-store.astro index d9230c9..6ecc31c 100644 --- a/src/pages/plain/app-store.astro +++ b/src/pages/plain/app-store.astro @@ -1,15 +1,17 @@ --- // Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run. // plain-source: src/pages/app-store.astro -// plain-source-sha256: 05caa5483c7cb824a1633a914ad2d24ea5ea2d26bead9f12b661f90fe92c0a7e +// plain-source-sha256: dd981b5e775bd19c13b658feece0b3a531984b01f220555142bae4131d553ef1 import PlainLayout from '../../layouts/PlainLayout.astro'; --- - +

Agent apps. One command away.

The App Store provides agent apps that install as sha256-pinned, signature-verified native services. Apps are auto-spawned by the daemon and callable over typed IPC.

+

An agent app is an installable capability — a database, a search backend, a sandbox, a payment rail — packaged as a typed JSON-in/JSON-out service that runs locally on your daemon. The loop is discover to install to call: browse the catalogue, install with one command, and call the app's methods from any agent on the network.

+

Publish an App

To publish an app, describe its methods in a guided submission. The adapter is then built, signed, and reviewed.

Once approved, the app is installable on the overlay network with the following command.

From bff547fab39215ebfc6528116aaf2e18223cbf74 Mon Sep 17 00:00:00 2001 From: pstayets Date: Fri, 14 Aug 2026 20:17:33 -0700 Subject: [PATCH 3/4] =?UTF-8?q?blog:=20Agent=20Connectivity=20Best=20Pract?= =?UTF-8?q?ices=20=E2=80=94=20expand=20network-stack=20post=20for=20GSC=20?= =?UTF-8?q?striking-distance=20query?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: pstayets --- public/llms.txt | 2 +- src/data/blogPosts.json | 12 ++-- ...st-practices-secure-scalable-systems.astro | 2 +- ...st-persistent-connections-for-agents.astro | 2 +- .../why-ai-agents-need-network-stack.astro | 68 ++++++++++++++----- 5 files changed, 61 insertions(+), 25 deletions(-) diff --git a/public/llms.txt b/public/llms.txt index 8a01542..70c649e 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -69,7 +69,7 @@ The managed control plane is in preview. Supported adapters can surface agent ac - [Nebula vs Tailscale vs ZeroTier: Overlay Network for AI Agents](https://pilotprotocol.network/blog/pilot-vs-tailscale-nebula-zerotier-ai-agents): Head-to-head comparison of the three most popular overlay networks and where Pilot fits for agent workloads. - [Benchmarking: HTTP vs UDP Overlay](https://pilotprotocol.network/blog/benchmarking-http-vs-udp-overlay): Latency, throughput, and NAT traversal benchmarks comparing HTTP/2 and Pilot's UDP overlay for agent communication. - [Persistent Connections for AI Agents](https://pilotprotocol.network/blog/move-beyond-rest-persistent-connections-for-agents): Compare REST, WebSocket, gRPC, and persistent UDP tunnels for agent messaging with code examples. -- [Why AI Agents Need Their Own Network Stack](https://pilotprotocol.network/blog/why-ai-agents-need-network-stack): The case for a dedicated network layer — permanent addresses, NAT traversal, encrypted tunnels, and cryptographic trust for multi-agent systems. +- [Agent Connectivity Best Practices: Why AI Agents Need a Network Stack](https://pilotprotocol.network/blog/why-ai-agents-need-network-stack): Agent connectivity best practices for multi-agent systems — durable addresses, NAT traversal, encrypted tunnels, and per-peer trust. - [Overlay Networking Explained](https://pilotprotocol.network/blog/overlay-networking-secure-ai-agent-communication-explained): A practical guide to overlay networking for secure AI agent communication — encapsulation, control planes, protocol trade-offs, and deployment patterns. - [NATS vs gRPC vs TCP vs Pilot Protocol](https://pilotprotocol.network/blog/pilot-vs-tcp-grpc-nats-comparison): Feature-by-feature comparison of four agent communication protocols with latency and throughput benchmarks. - [Multi-Agent System Security: Network Defense Strategies](https://pilotprotocol.network/blog/network-security-for-multi-agent-systems-key-strategies): Layered defense, secure protocols (MCP, A2A), and how to protect AI agent networks from compromise. diff --git a/src/data/blogPosts.json b/src/data/blogPosts.json index df4503b..60c0bc8 100644 --- a/src/data/blogPosts.json +++ b/src/data/blogPosts.json @@ -32,7 +32,7 @@ { "slug": "build-agent-app-turn-api-into-tool", "title": "How to Build an Agent App: Turn Your API Into an Agent-Native Tool", - "description": "Turn an existing API into an installable agent app on Pilot Protocol — the discover, install, call loop, what to prepare, and how to publish.", + "description": "Turn an existing API into an installable agent app on Pilot Protocol \u2014 the discover, install, call loop, what to prepare, and how to publish.", "date": "Jul 5", "category": "Blog", "tags": [ @@ -62,7 +62,7 @@ { "slug": "overlay-network-ai-agents", "title": "Overlay Network for AI Agents: Architecture and Trust Model", - "description": "What an overlay network for AI agents needs — persistent addressing, NAT traversal, encrypted transport, and per-peer trust — and how Pilot Protocol implements it.", + "description": "What an overlay network for AI agents needs \u2014 persistent addressing, NAT traversal, encrypted transport, and per-peer trust \u2014 and how Pilot Protocol implements it.", "date": "Jul 1", "category": "Blog", "tags": [ @@ -1153,13 +1153,15 @@ }, { "slug": "why-ai-agents-need-network-stack", - "title": "Why AI Agents Need Their Own Network Stack", - "description": "A2A assumes HTTP endpoints. MCP assumes reachable servers. 88% of networks involve NAT. The agent ecosystem is missing its TCP/IP layer.", + "title": "Agent Connectivity Best Practices: Why AI Agents Need a Network Stack", + "description": "Agent connectivity best practices for reliable multi-agent systems: durable addresses, NAT traversal, encrypted tunnels, and per-peer trust.", "date": "Feb 2", "category": "Architecture", "tags": [ "opinion", - "ai-agents" + "ai-agents", + "networking", + "best-practices" ], "banner": "banners/why-ai-agents-need-network-stack.webp", "iso_date": "2026-02-02" diff --git a/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro b/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro index 27f1109..2037c74 100644 --- a/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro +++ b/src/pages/blog/ai-networking-best-practices-secure-scalable-systems.astro @@ -213,7 +213,7 @@ const bodyContent = `