security · cross-agent integrity
Signed envelopes.
Every cross-agent message in Junie is wrapped in a signed envelope: Ed25519 signature, replay-resistant nonce, zone-tagged payload, and a verifiable identity on each end. This page is the security explainer for couples and teams who want to know what that actually protects against.
What we mean by signed envelopes.
A signed envelope is the unit of cross-agent traffic. Every message your agent sends to another paired agent is wrapped with a sender identity, a recipient identity, a timestamp, a one-time nonce, the zone-tagged payload, and an Ed25519 signature over all of it.
The envelope is the integrity and authenticity boundary. Tampering invalidates the signature; replays are rejected by the timestamp and nonce checks; impersonation requires the private key, which never leaves the originating agent.
The threat model.
Signed envelopes are designed to defend against a specific set of threats. Stating them up front so the guarantees are concrete:
- Tampering in transit. An attacker on the path between two agents cannot modify the envelope without the recipient detecting it.
- Replay. An attacker cannot capture an envelope and re-send it later to make the recipient act on it again.
- Impersonation. An attacker cannot craft an envelope that appears to come from your paired partner’s agent.
- Pairing-handshake interception. An attacker who interposes during pairing fails the safety-number check and is detected before the channel is trusted.
- Cross-zone leakage. A request from a paired agent for content tagged in a zone they don’t have grant on fails before the payload is materialized.
What’s actually signed.
Six fields. The signature covers all of them as a single message; modifying any one invalidates it.
- sender_pk — public key of the sending agent (32 bytes).
- recipient_pk — public key of the intended recipient agent.
- timestamp — unix milliseconds when the envelope was signed.
- nonce — 16 random bytes, one-time use within the timestamp window.
- payload — the request, response, or memory operation. Carries the zone tag.
- signature — Ed25519 signature over the concatenation of the above.
Ed25519 keypair generation and exchange.
When an agent is provisioned, it generates an Ed25519 keypair using the operating system’s CSPRNG. The private half lives only inside the agent’s isolated pod (on the hosted plan) or wherever the self-hosted operator stores it. The public half is exchanged during pairing.
Pairing produces:
- — Both agents’ public keys are stored in each other’s pairing record.
- — A safety number is derived from the two public keys (deterministic; same on both sides).
- — The pairing record is tagged with a unique pairing ID and zone-grant defaults.
From this point forward, every envelope between the two agents is signed with the originator’s private key and verified against the stored public key on the other end.
Replay protection.
A signed envelope on its own is valid forever. Without replay protection, an attacker who captured an old envelope (a confirm-dinner-Saturday from last month) could re-send it next week and have it accepted. Two mechanisms prevent that:
- Timestamp window. The recipient rejects any envelope older than 5 minutes. Clock skew is tolerated up to a small bound; anything beyond that fails.
- Nonce cache. Every accepted envelope’s nonce is stored for the duration of the timestamp window. Re-sending the same envelope inside the window — same signature, same nonce — is rejected on the duplicate-nonce check.
The combination means an envelope is valid only inside a narrow window and only once. The cache is small and self-pruning.
Safety numbers.
Signing prevents tampering, but signing alone doesn’t tell you that you paired with the right agent on the other end. The safety number does.
During pairing, both agents derive the same short string (30 digits, displayed as 5 groups of 6) from the two exchanged public keys. The derivation is deterministic — same keys, same number — so reading it aloud or comparing on each phone confirms you paired with the right agent. The pattern is the same one Signal uses for its safety numbers.
A man-in-the-middle attacker who substituted a different public key during the handshake would produce a different safety number on one side; the verification step catches that before the channel is trusted.
What signed envelopes don’t protect against.
A security explainer that doesn’t name what it doesn’t do is not honest. Three categories of threat live outside the envelope’s scope:
- Device compromise. Someone with your unlocked phone is you, as far as Junie’s agent is concerned. Set up the device PIN (separate layer) for an additional check.
- LLM-provider compromise. Junie runs on top of frontier models hosted by their providers. Their security posture is theirs; we route sensitive content through redaction layers but do not claim guarantees beyond what those providers commit to.
- Traffic-analysis on metadata. The contents of envelopes are protected. The fact that two agents communicated, when, and how often is observable at the network layer.
Compared to other AI assistants.
Most consumer AI assistants are single-tenant: one conversation, one model provider. There’s no cross-agent traffic to sign because there’s no paired counterpart. The trust model is provider-policy: they tell you what they do with your data and you take their word for it.
Junie’s pairing model creates a class of communication that does need cryptographic protection (between two agents), and the signed-envelope protocol is how we provide it. The trust model on the cross-agent channel is cryptographic — not policy.
questions
Frequently asked.
- Is Junie end-to-end encrypted?
- Cross-agent traffic is end-to-end signed and replay-protected; the integrity and authenticity guarantees are equivalent to E2E encryption's. Payload encryption-at-rest follows the standard cloud KMS model on the hosted plan; self-hosted deployments can configure their own KMS. The pairing handshake produces session keys that never leave the agents involved.
- What cipher is used for the signature?
- Ed25519. Each agent generates its own Ed25519 keypair at provisioning. Signatures cover the full envelope (sender, recipient, timestamp, nonce, payload). The library used is the standard Go x/crypto/ed25519 package; the key generation runs inside the agent's pod and the private key never leaves it.
- How does Junie protect against replay attacks?
- Two mechanisms: a five-minute timestamp window (older envelopes are rejected) and a nonce cache (every accepted envelope's nonce is recorded; duplicate nonces in the window are rejected). An adversary who captured an old envelope cannot replay it minutes later or weeks later.
- Can someone with my account password read my private memory?
- Account access lets someone use your agent — but the private zone gate is enforced by the agent runtime, not by the account. Cross-agent reads still fail at zone-mismatch even from inside an authenticated session if the requesting agent isn't your own. (For real-world threat models that include device theft, set up the device-pairing PIN — that's a separate layer documented in the device-pairing spec.)
- What does Junie not protect against?
- Compromise of the device itself (someone with your unlocked phone has your agent), compromise of the underlying LLM provider (we use frontier models hosted by their providers; their security posture is theirs), and traffic-analysis attacks on the network metadata between agents (the envelope contents are protected; the fact that a message was sent is not).
Verifiable, by design.
Set up your account, pair an agent, and read your safety number out loud once. Free in private beta.