Inbot handles mail and credentials on the owner's machine and connects to Cloudflare for mail transport and optional remote access. We take reports about these boundaries seriously.

Report vulnerabilities privately. Do not open a public issue, discussion, or pull request.

• Preferred: open a private security advisory on GitHub.
• Alternative: email security@kerd.dev.

Include the affected Inbot version, your operating system, reproduction steps using synthetic mail and a temporary home, and the impact you observed. Never include real mail, credentials, keys, or signed download URLs. We acknowledge reports as soon as we can, keep you updated while we investigate, and credit you in the advisory unless you prefer otherwise. There is no guaranteed response or fix deadline.

The latest 0.1.x release receives security fixes. Older patches and unreleased development snapshots are not supported; reproduce on the latest patch where possible.

Inbound mail is age-encrypted to the owner's public key before it waits in the Cloudflare R2 buffer. On the host, mail is stored in an encrypted SQLite database. Inbot is zero-knowledge at rest, not end-to-end encrypted: the mail provider sees plaintext in transit, outbound mail passes through it, and Cloudflare terminates public TLS for remote access. Provider-generated delivery events can contain plaintext subjects in their Queue until acknowledged.

Email content is untrusted data. It cannot grant permissions or widen an agent's scope. Inbox scope, permission whitelists, hidden labels, and direct, approval, or read_only send policies are enforced by the service. Owner management operations are unavailable to agent credentials and are not exposed as MCP tools.

In scope:

• Plaintext mail, keys, or credentials leaking through Inbot storage, cloud buffering, logs, or diagnostics
• Bypassing authentication, browser Origin or CSRF checks, OAuth audience binding, or credential revocation
• Agents accessing inboxes, hidden messages, attachments, or operations outside their grants, or bypassing send policies
• Untrusted email content executing scripts in the owner UI or causing Inbot to treat message content as authorization
• Bypassing the tunnel path allowlist, reaching excluded owner management routes, or using a local owner bearer token through the tunnel
• Encryption, key handling, signed download, or webhook authorization flaws in Inbot

Out of scope:

• Attacks that require an already compromised host account or access to the owner's unlocked credential store
• Provider access to plaintext in transit and the delivery-event metadata described above
• Actions the owner intentionally authorizes, such as sending mail or granting an agent access to an inbox
• An external agent following malicious email instructions within permissions it already has, without an Inbot authorization bypass
• Denial of service through traffic volume alone, or vulnerabilities in third-party services without an Inbot-specific impact

Only test against machines, accounts, domains, and inboxes you own. Use synthetic mail and isolated homes; do not test against another owner's instance or mail infrastructure.

The local owner updater downloads releases only from kerddotdev/inbot on GitHub. It verifies the exact platform archive against SHA256SUMS before extraction and, on macOS, runs codesign --verify --strict on the bundled Node binary and requires Team ID 7LA5DMHTL9. Verification failure prevents the launcher switch. The updater and release tooling share the checksum verifier. HTTPS and the GitHub release account remain trust boundaries: a checksum hosted beside an archive is not an independent publisher signature. macOS releases are signed and notarized during publication; the updater checks the Node signature, not a fresh notarization verdict or every native module individually. GitHub provenance attestations are published but must be verified separately with gh attestation verify.

Automatic updates are enabled by default only for installed background services. The owner can disable them locally. Status and preference routes require owner credentials, enforce browser CSRF, and are excluded from the tunnel. There is no REST or MCP operation to install a release. Applying an automatic update waits for the existing shutdown path before switching versions and requesting a manager restart. Updates never downgrade; older packages are retained, but rollback after a database migration is unsupported.