Common questions about amesh, device-bound identity, and how it compares to alternatives.
mTLS binds identity to a certificate file that can be copied. amesh binds identity to a private key that's protected by the OS keychain or TPM and never leaves the device. mTLS also requires a PKI (CA, cert issuance, renewal, CRL/OCSP) — amesh has zero CA infrastructure. Pairing is two CLI commands.
OAuth2 client credentials is still a shared secret (client_secret) that gets exchanged for a token. If the secret leaks, any machine can get tokens. amesh has no secret to leak — only the device that holds the private key can sign valid requests. OAuth also requires an auth server; amesh is stateless after pairing.
A secrets manager manages secrets; it does not eliminate them. Your service still fetches a secret string, holds it in memory, and sends it over the wire. If the manager is unreachable, your service can't authenticate. The manager itself needs authentication — how does your server authenticate to it? Usually with another secret. Secrets managers are a real improvement over loose .env files, but amesh operates at a different layer: it removes the string entirely, so there's nothing to manage in the first place.
Not really. Device-bound identity requires stable hardware or a persistent filesystem. In serverless environments, every invocation is a fresh container with no stored state — there's no 'device' to bind to. amesh is designed for long-running machines: API servers, microservices, developer laptops, CI runners with persistent state, and edge devices.
No. Browsers don't have a concept of device identity, and client-side JavaScript can't access OS keychains or TPMs. For browser auth, use WebAuthn/passkeys (which also use hardware keys but via a different API). amesh is for machine-to-machine — server, CLI, and daemon authentication.
You don't — device keys don't expire. If a device is compromised, you revoke it with amesh revoke <device-id> and only that device loses access. A new device generates its own key via amesh init, pairs, and is trusted. Every other device continues working. There's no coordination problem.
From any other trusted controller, run amesh revoke <device-id> on each target that trusted the lost device. The lost laptop's key can no longer authenticate. Because trust is one-way (controller → target), the lost laptop cannot revoke other devices.
Yes. The private key is on the device, and signing is a local operation. The relay is only needed once — for initial pairing to exchange public keys. After pairing you can shut the relay down entirely. All request signing and verification is stateless.
No, but neither is any widely-deployed signature scheme in 2026. amesh uses P-256 ECDSA because it's the most broadly supported in hardware (Secure Enclave, TPM 2.0, YubiKey). When post-quantum signatures (ML-DSA) reach hardware, amesh can add them as a v3 wire format. The protocol already versions the signature algorithm field.
The cryptographic primitives come from the noble libraries (noble/curves, noble/hashes, noble/ciphers), which are well-audited open-source implementations of standard algorithms. The amesh protocol itself has had a security review by the author (see the security audit report in GitHub). A formal third-party audit is planned before a v1.0 release.
amesh gives you per-device audit trails, non-repudiable request signatures, and instant revocation — all things auditors care about. It doesn't automatically make you compliant, but it removes the 'shared API key with unknown blast radius' finding that auditors typically flag. Every request has a verified device ID in logs.
Yes — MIT licensed, full source on GitHub, no paid tier, no telemetry, no phone-home. The relay is stateless and trivial to self-host (one Docker container). The CLI and SDKs are published to npm. You can audit, fork, and self-host everything.
Don't see your question? Open an issue on GitHub.