Security center · v1 preview
Private by design.
Precise about the limits.
Text and image bytes are encrypted in the participating browsers. Cloudflare receives ciphertext and limited delivery metadata—not room plaintext or room keys.
Architecture
What protects each layer
AES-256-GCMEncrypted and authenticated in the browser before upload
ML-KEM-768 + P-256 + HKDF-SHA-256Hybrid post-quantum recipient encryption; independent audit required
Shared AES-256 room keyClassical key delivery in the current preview
P-256 ECDH + HKDF-SHA-256Classical in the current preview
Separate hashed capabilitiesA room-scoped write token and optional read token
WebAuthn passkeyNo password, email, or recovery secret held by shhh.bot
Cloudflare D1 + R2Ciphertext, identifiers, timestamps, sizes, and delivery metadata
Encryption boundary
Plaintext stays at the endpoints
Conversation rooms use a random shared room key delivered to the approved agent browser inside an encrypted pairing envelope. Each text message and image uses authenticated AES-256-GCM encryption with a unique random nonce and context-bound additional data.
New delivery-only rooms use different key material: the human retains the ML-KEM-768 and P-256 private keys, while the agent receives only their public keys and a write capability. Each delivery derives a fresh AES-256-GCM message key from both components. Changing database permissions can reveal ciphertext to the agent, but not the human’s private keys needed to decrypt it.
Room read and write capabilities are random, independent, and stored by the service only as SHA-256 hashes. Existing delivery rooms created before this protocol must be destroyed and re-paired to receive hybrid protection.
Post-quantum status
Post-quantum delivery, with a precise scope
New delivery-only messages combine ML-KEM-768, standardized by NIST for post-quantum key establishment, with classical P-256. The hybrid construction is designed to keep a delivery confidential if either component remains secure. AES-256-GCM protects the resulting message and image ciphertext.
The delivery protocol is versioned and downgrade-rejecting, with tests for tampering, wrong recipients, message substitution, and database permission changes. It has not received an independent cryptographic audit. Pairing and two-way conversation key exchange still use classical P-256 and are not post-quantum.
Metadata
What the service can still observe
- Ciphertext sizes and whether a message uses blob storage
- Room and message identifiers
- Creation, upload, retrieval, report, and deletion times
- The authenticated owner’s Cloudflare-verified IP when a room is approved, encrypted under a separate service key and retained for no more than 30 days
- Network-security telemetry processed by Cloudflare
- Readable text deliberately submitted through the abuse-report form
We still can’t see the content of your room. The approval-IP record is separate metadata; it does not provide access to room keys or plaintext. End-to-end encryption protects content, but it does not make traffic patterns, endpoint activity, or service abuse invisible.
An IP address may be shared, dynamic, proxied, or masked. It is supporting evidence for abuse response—not proof of a person’s identity. See the privacy notice.
Endpoint reality
The browsers necessarily see the message
shhh.bot is designed to keep the final text or image handoff out of the AI harness’s visible chat window and saved transcript. It does not make that work invisible to the provider operating the agent.
The human and agent endpoints decrypt content in order to display or process it. Malicious browser extensions, compromised devices, screenshots, copied files, or injected application code can expose plaintext. An AI provider may retain prompts, outputs, browser activity, screenshots, or reasoning traces independently of shhh.bot.
Deleting a message removes the stored ciphertext and signals official clients to remove it. It cannot erase copies already retained, exported, photographed, or logged by an endpoint.
Authorization
What QR pairing proves
Pairing proves that a passkey-authenticated owner approved one browser and gave it room-scoped capabilities. It keeps the owner’s passkey and account session off the agent computer. It does not cryptographically prove that software rather than another person controls that browser.
Safety
Encryption is not permission to cause harm
Human-to-human use and unlawful material or communication are prohibited. Because shhh.bot cannot scan encrypted room content, its controls are accountable ownership, scoped capabilities, rate limits, reports, suspension, deletion, and lawful process.
Do not send suspected CSAM to shhh.bot. Submit identifiers and a concise description through the protected reporting form; contact emergency services when someone is in immediate danger.
Assurance
Preview, not a security certification
This implementation has not received an independent protocol, application-security, or cryptographic audit. Use test content until those reviews are complete. Material findings and protocol-version changes will be published here.