This document scopes mlxMesh for an external security review and tells anyone who finds a vulnerability how to report it. It is the reviewer's map: assets, trust boundaries, the cryptographic inventory, and where the trust-critical code lives. The README security model has the narrative; this is the structured scope.

Email jmelton@americancode.org with details and a reproduction. Please do not open a public issue for a security bug. Expect an acknowledgement within a few business days. There is no bug-bounty program yet; credit is given in the release notes unless you prefer otherwise.

Releases are signed with cosign in keyless mode (Sigstore OIDC) — there is no long-lived public key to distribute; the signer's certificate is embedded in the signature bundle and bound to an identity + OIDC issuer. To verify a download, check the bundle against this project's signer identity:

• Signer identity (certificate-identity): jmelton@americancode.org
• OIDC issuer (certificate-oidc-issuer): https://login.microsoftonline.com

cosign verify-blob --bundle dist/SHA256SUMS.sigbundle dist/SHA256SUMS \
  --certificate-identity jmelton@americancode.org \
  --certificate-oidc-issuer https://login.microsoftonline.com
sha256sum -c dist/SHA256SUMS   # then confirm artifact integrity

A valid signature proves the artifacts were signed by that Microsoft/Azure AD identity via Sigstore. See RELEASING.md for the signing side.

A credit-based, no-native-token distributed inference network. The security question that dominates everything: if the client and node code are open and forkable, what stops someone minting credits, spoofing the system, or knocking it over? The review should judge the answer against the code, not the prose.

1. Client ↔ Coordinator. Untrusted clients. Credit gate, write-path Ed25519 signatures, API-key auth, rate limits, per-account quotas, read-endpoint protection. Entry: cmd/coordinator/main.go (handlers + authMiddleware).
2. Node ↔ Coordinator. Independently-operated, semi-trusted nodes. Node identity signing, coordinator-observed earnings (not node self-report), TOFU TLS-fingerprint pinning, tier spot-checks. Entry: internal/coordinator/{router,verification,registry}.go.
3. Coordinator ↔ Coordinator (federation). Peer pods witness each other's signed ledger events; a rogue pod's balance claim is auditable against its own signed history. Not BFT consensus — see Known limitations. Entry: internal/federation.
4. Coordinator ↔ Directory. Directory is a transport, not an authority; TOFU-pinned/allowlisted signed pod registration. Entry: internal/directory/pinning.go, cmd/directory/main.go.
5. Node ↔ arbitrary payload host (SSRF surface). A node fetches a client-supplied pointer URL. Guarded by an allowlist re-checked on every redirect hop + a connect-time IP check. Entry: internal/httpmw/ssrf.go, internal/agent/agent.go (fetchAndDecryptPayload).

Cross-language crypto compatibility (Go ↔ Swift CryptoKit) is a specific audit target: the AES-GCM/HKDF payload path and the wallet challenge-response must interoperate exactly, and any drift is a correctness and security bug.

Multiple internal multi-angle passes have run against recent diffs and found + fixed real issues, documented so the external reviewer can start from a known baseline rather than re-deriving it:

• SSRF redirect + DNS-rebinding bypass in the node payload fetch — fixed (httpmw.SafeFetchClient: per-redirect re-validation + dialer Control IP check). Tests: internal/httpmw/ssrf_test.go, clientip_test.go.
• Non-constant-time bearer comparison (federation + admin keys) — fixed with crypto/subtle.
• Directory missing the coordinator's DoS floor — fixed (body cap + concurrency + per-IP limit added).
• Identity-file permissions not tightened on rewrite — fixed (internal/identity/store.go).
• Several speculative DoS claims refuted against the code (e.g. reservation churn never touches a node's in-flight counter, so it can't starve routing).

These are deliberate, documented design boundaries — a reviewer should confirm they are what they claim, not report them as surprises:

• No BFT consensus / staking. Federation is PKI-based witnessing among a curated/TOFU-pinned set of pods. A compromised pod (not merely impersonating) can misbehave until a peer audits it; there's no automatic quarantine. The no-native-token design means there's no stakeable asset for slashing.
• Attestation is opt-in and self-declared unless Secure-Enclave-backed. The HasSecureEnclave bool is never trusted for routing; only coordinator-verified enclave attestation gates HIGH-sensitivity jobs.
• Read-endpoint protection and per-account quotas are opt-in flags. A public deployment must enable them; the sim/dev default is open.
• Single coordinator per region, SQLite ledger. No HA/failover yet; a managed datastore + coordinator HA are on the release path.
• Quantum vulnerability. Ed25519 (used for node/coordinator/wallet identity) would fall to a sufficiently large quantum computer running Shor's algorithm. This is true of all ECC-based systems in production today (TLS, SSH, Signal, Bitcoin). NIST finalized post-quantum signature standards in 2024 (ML-DSA/Dilithium, SLH-DSA), but migration is a multi-year industry-wide project. This is a known long-term consideration, not an immediate action item.

1. The settlement ledger + credit/debit paths (money integrity, double-spend, overdraft, reconciliation soundness).
2. The cross-language payload crypto (Go ↔ Swift AES-GCM/HKDF/ECDH).
3. The wallet challenge-response + device-linking auth.
4. authMiddleware and the self-authenticating-write allowlist (a too-broad entry there defeats the write gate).
5. The federation witnessing/audit invariant under adversarial event histories.