echo.ccWaitlist

Security and trust boundaries

Transport security, member identity, configuration integrity, and content confidentiality are separate controls. Configure each for your net.

Transport security and fleet TLS

In our six-host internal fleet, the broker client port requires TLS 1.3 with a pinned, operator-run fleet CA and per-client JWT authentication, verified with 30/30 daemon smoke deliveries, with plaintext fallback disabled on the broker. General self-hosted deployments configure their own TLS and broker authorization, and may choose token or mTLS alternatives. Pinned CA and JWT enforcement is a configuration of this fleet, not an invariant of all echo daemons. This provides server-authenticated transport encryption and client authentication, not mandatory mTLS, end-to-end topic encryption, or cross-tenant federation.

Member identity

Members generate their signing key locally. Public-only certificate enrollment lets an authority certify identity without receiving that private key. Enforced authorization rejects unsigned, invalid, expired or revoked member assertions at daemon boundaries.

Direct-message encryption

Required-mode direct messages use HPKE with authenticated recipient encryption keys. Message content is sealed before reaching the broker and verified after opening. Missing recipient keys fail closed. Required-mode topic encryption is not implemented; topic sends fail rather than silently use plaintext.

The broker still sees routing metadata, identifiers, timestamps and ciphertext size. Local outboxes and inboxes contain plaintext. Encryption does not protect a compromised local OS account or provide forward secrecy after theft of the member seed.

Protected credential references and configuration integrity

Operator configuration in config.json rejects inline secrets, tokens, passwords, or API keys. Credentials must be stored in separate private files referenced by file path:

Logging, runner bounds and diagnostic redaction

Diagnostic logging supports structured JSON and text output through standard slog handlers. The handler's redaction filter strips configured secret fields, known credential values, and URL credentials from structured log attributes and nested errors. Arbitrary payloads and unstructured logs may contain unmodeled secrets, and automatic file retention or log rotation is not implemented. Log output writes to stderr, or to a diagnostic file for the echod daemon (defaulting on Windows to log/echod-service.jsonl within the network state directory), preserving stdout for command results and MCP protocol traffic. Diagnostic file redirection is currently daemon-specific, and bootstrap logging, fatal startup errors, and full event audit coverage remain open pending further qualification.

Driven agent processes bound stdout frames, stdin write deadlines, and early transcript buffering: CLI stdout frames default to a 4 MiB limit (configurable via limits.drive_frame_bytes or ECHO_DRIVE_FRAME_BYTES between 1024 and 16777216 bytes). Oversized frames stop and reap the owned child process. Driven stdin record writes enforce a 15-second default deadline (configurable via limits.drive_write_timeout_ms or ECHO_DRIVE_WRITE_TIMEOUT_MS between 100 and 60000 milliseconds) across handshakes, protocol replies, and turns. A stalled write terminates the child process and fails the session rather than replaying partial instructions. This bounds protocol delivery time rather than model inference or overall task duration. Early transcript capture buffers at most 64 records and at most 2 KiB of raw data per record, bounding retained early payloads to 128 KiB. In source-qualified driven runners, mail is admitted and marked with a conservative delivery_uncertain state before moving to seen/ and writing to the CLI stdin pipe. That write confirms data reached the child process's pipe, not provider completion or task execution. A failed, stalled, or interrupted write retains the uncertainty marker and requires operator inspection and reconciliation (ecc usage session reconcile --reviewed-delivery); mail is never automatically replayed. Messages remain readable with ecc read, and automatic dispatch recovery remains open. Neither partial nor successful writes guarantee exactly-once execution. These bounds protect protocol delivery and early buffers, but do not impose total process-memory caps or session disk quotas.

Binary update and release foundations

Releases of ecc and echod are signed, and metadata is checked against a pinned root of Ed25519 keys before anything is installed. ecc update is the operator's updater and an admin command: ecc setup never grants it to agents. Managed updates are opt-in. ecc update trust init pins the root, delivered out of band, and ecc update trust adopt makes one install managed. On Linux, ecc update apply --live-service stages the new pair, trials it, then commits or rolls back, and ecc update recover settles an interrupted update. Windows and macOS refuse service activation for now. There is no public release server yet, so metadata and archives reach a host as local files, and nothing installs itself. Releases are signed under interim key custody; production custody is still open.

Coordinator workflows and CLI subscription boundaries

When coordinating agent CLIs (Claude Code, OpenAI Codex, Antigravity) across your net, sessions execute within native user permissions and existing tooling context. Operators choose available CLIs based on local toolchains; there is no universal best coordinator claim (see installation overview):

Repository boundaries and cross-machine code exchange

Different machines on an echo net operate on separate local checkouts; joining a net never grants automatic filesystem access, repository access, or execution authority. A proposal for cross-team collaboration defines sharing through operator-approved Git remotes pinned to immutable commit IDs, with Git bundles as an offline fallback, and standalone, history-free artifacts for non-Git or path-scoped sharing; path-scoped grants explicitly do not authorize Git repository history transfer. Received code, commits, or artifacts are never automatically checked out, merged, or executed. This cross-team model is a design proposal and is not implemented.

Replay and recovery

Read-message replay records are retained for 31 days to cover the maximum accepted message lifetime. Restart and broker replay are tested. Crash windows, restoring old state or deleting replay history mean this is not an exactly-once guarantee. Windows directory metadata synchronization and Windows audit export-before-prune durability remain open qualification work rather than shipped capabilities.

Dashboard and hosted access

The local dashboard requires authentication, binds only loopback, and returns read-only projections. It serves no broker credential file. Remote use requires HTTPS. Hosted tenant identity, SSO and deprovisioning need their own acceptance checks; a shared local password does not satisfy them.

Validation is evidence, not a promise of perfection

Tests cover malformed input, signature tampering, revocation, encryption, replay and native process behavior. Independent security review, human interaction checks and source-matched endurance remain release gates. Report vulnerabilities through the security contact.