Mailbuttons is an Agent Mail API operated by Code Cutter Limited (UK company no. 08453060). Because customers run AI agents against inbound mail through our platform, the security of the software we build is inseparable from the security of their data. This policy sets out how we develop that software securely.

# Purpose and scope

This policy establishes secure development practices for all Mailbuttons software: the Rust/Axum backend, the Next.js frontend, the tenant-aware JMAP proxy, database migrations, and the custom-agent execution sandbox. It applies to all code authored or accepted into the production codebase. It supports the requirements of ISO/IEC 27001:2022 Annex A 8.25 (secure development life cycle), 8.26 (application security requirements), 8.27 (secure system architecture) and 8.28 (secure coding).

# Policy

Secure by design. Security is considered at design time, not retrofitted. New features that touch authentication, tenant isolation, mail handling or customer data are subject to threat-aware design: we reason explicitly about the attacker, the trust boundaries crossed, and the failure modes, and we prefer fail-closed behaviour. Tenant isolation in the JMAP proxy is treated as a primary security boundary.

Code review before merge. All changes land in git via reviewed commits. No change reaches the production codebase without review. For security-sensitive changes, the team additionally performs adversarial security review — actively attempting to break the proposed design or implementation before it is accepted.

Secrets management. Secrets are never committed to source control. Configuration and credentials for development and production are kept strictly separate, so that a development environment can never reach production data or services. Secrets at rest are encrypted with AES-256-GCM.

Least privilege by design. Services are designed to hold only the privileges they need. Database roles, API credentials and inter-service access are scoped narrowly, limiting the blast radius of any single compromised component.

Input validation and output encoding. Untrusted input — including inbound email content, JMAP payloads and API requests — is validated at trust boundaries. Output is encoded appropriately for its context to prevent injection. Rust's type system and memory safety are leveraged as a baseline defence.

The custom-agent sandbox. Customer-supplied agent code is a deliberately hostile input and is treated as such. It runs in a hardened WASI-CPython/wasmtime sandbox on a separate, network-isolated VM reached only over WireGuard. The sandbox has no socket or filesystem access, enforces fuel, epoch and memory limits, and is fronted by an always-on SSRF guard. This is the concrete embodiment of secure-by-design isolation in our architecture.

Dependency management. Third-party dependencies are reviewed before adoption and kept current. We aspire to automated dependency vulnerability alerting and static analysis (SAST) as our tooling matures; today this is supplemented by manual review and the practices in our Vulnerability and Patch Management Policy. We state this honestly rather than overclaim.

Security testing. Changes are exercised through local and CI builds, typecheck and cargo tests before deployment. Security-relevant behaviour (isolation, authorisation, validation) is tested directly, and the adversarial review above acts as a human security test on sensitive changes.

# Responsibilities

The ISMS Owner is accountable for this policy, for ensuring reviews and adversarial assessments occur, and for the secure design of new features. As a founder-led micro-team, the ISMS Owner currently performs both authoring and review; we rely on disciplined practice and tooling rather than team size.

# Review

This policy is reviewed at least annually and after any material change, and is approved by the ISMS Owner.

Related: Change Management Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy, Access Control Policy