Mailbuttons is operated by Code Cutter Limited (UK company no. 08453060). This policy governs how access to systems, infrastructure and customer data is granted, controlled and removed, so that the right people have the right access and no more.

# Purpose and scope

This policy ensures access to Mailbuttons systems and data is granted on a least-privilege, need-to-know basis and is properly authenticated, reviewed and revoked. It supports Annex A controls A.5.15 to A.5.18 and A.8.2 to A.8.5. It covers all human and machine access to the application, infrastructure, supplier accounts and customer data, and applies to staff and contractors alike.

# Policy

Identity and authentication. Human identity is managed through Kanidm OIDC with passkeys as the authentication mechanism. Multi-factor authentication via passkeys is mandatory for all access to systems holding or controlling customer data. Shared or generic accounts are not permitted; every action must be attributable to a named identity.

Least privilege and need-to-know. Access is granted only where there is a genuine operational need and is limited to the minimum required. Roles are defined so that permissions are bundled by function (role-based access) rather than granted ad hoc, and elevated permissions are kept to the smallest possible set.

Production and administrative access. Access to production systems, databases and administrative functions is restricted to authorised engineers only. For a single-engineer team this means the founder; as the team grows, production access is granted explicitly and recorded.

Application-level tenant isolation. The tenant-aware JMAP proxy is itself an access control: it scopes every request to the authenticated customer, injecting tenant context and preventing one tenant from reaching another's mailboxes or data. This isolation is treated as a security control and must not be bypassed.

API keys and capability tokens. Customer API keys are scoped to a single tenant and the minimum capabilities needed. Custom agent runs are granted short-lived, per-run capability tokens rather than broad standing credentials. Keys and tokens are stored encrypted at rest as described in the Cryptography Policy, are never embedded in source, and can be revoked at any time.

Secure remote access. Administrative access to the network-isolated agent executor VM is only over WireGuard. The executor VM has no general inbound exposure, and the always-on SSRF guard constrains what agent code can reach from inside the sandbox.

Segregation of duties. Where the size of the team allows, sensitive actions are separated so that no single step is unchecked. Where full segregation is impractical for a micro-team, we compensate with logging, alerting and periodic review so that privileged actions remain traceable and reviewable after the fact.

Access reviews. Access rights are reviewed periodically, at least annually, to confirm they remain appropriate and to remove anything no longer needed. Supplier accounts (Fasthosts, Cloudflare, Backblaze, Stripe, Anthropic) are included in these reviews.

Revocation. When anyone leaves or changes role, their access is revoked or adjusted the same day, in line with the Human Resources Security Policy. Any shared secrets they could have known are rotated.

# Responsibilities

The ISMS Owner is accountable for this policy: for authorising access, running periodic reviews and ensuring timely revocation. Everyone with access is responsible for using only the access they are granted, protecting their credentials, and reporting any access that appears excessive or incorrect to [email protected].

# Review

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

Related: Human Resources Security Policy, Acceptable Use Policy, Cryptography Policy.