Built secure, not retrofitted.

Stampify reads directory metadata (names, titles, contact details, group memberships) using the minimum read-only OAuth scopes on Microsoft Graph and Google Directory. It never holds a scope that can read mailbox content, files, or calendars on either vendor.

Each tenant is isolated by row-level permissions in the database. Vendor refresh tokens are encrypted at rest with a key kept outside the database. Rendered signatures contain no tracking pixels by default. The admin dashboard ships zero third-party scripts.

Four steps from admin consent to a rendered signature. Each step lists what Stampify is allowed to do at that boundary.

1. Step 01

   Admin consents

   A tenant admin signs in to Stampify via Microsoft 365 or Google Workspace OAuth and grants the read-only directory scopes above. No mail, files, or calendar scopes are requested at any point.

2. Step 02

   Stampify reads directory

   Using the granted scopes, Stampify reads names, titles, phones, group memberships, and primary emails. It writes one row per user in the tenant's isolated dataset.

3. Step 03

   Render at compose time

   When a user composes a message, the Outlook or Gmail add-in calls the Stampify render endpoint with a vendor-signed identity token. The endpoint resolves the user, merges template + global brand + per-user fields, and returns HTML.

4. Step 04

   Add-in inserts the signature

   The host (Outlook / Gmail) inserts the returned HTML into the compose body via its built-in signature insertion API. Stampify never reads the message body, recipients, subject, or thread history.

Both vendors list the scopes Stampify requests, plus, more importantly, the ones we never request. If you reviewed an admin-consent screen and saw a scope that isn't in the "requested" list below, please report it as a security issue.

The Outlook add-in carries its own MailboxItem.ReadWrite.User grant via the add-in manifest. That grant is scoped to the add-in's client-side runtime, used only to insert HTML into the active compose body. Stampify's backend cannot use it. The Gmail add-on follows the same pattern, the backend never holds a Gmail-write token.

Every row in every table carries a tenantId. Every read and write is filtered by row-level permissions in Appwrite, scoped to Role.team(tenantTeamId). The render endpoint receives a vendor-signed identity token, validates it against the vendor's JWKS, and resolves the caller's tenant before any data access. There is no shared admin path that bypasses these scopes.

• Reads scoped to the caller's Appwrite Team (per tenant).
• Writes require an admin role in the same team.
• Cross-tenant queries are not possible without a manual permission edit on the row itself.
• A one-click tenant delete cascades through users, signatures, templates, sync history, and licenses.

TLS 1.2+ on every public surface. Application-layer encryption for the values that matter most:

• Vendor refresh tokens (Microsoft / Google) are encrypted before they reach the database.
• Encryption key lives in a separate secret store (environment / KMS), never the database.
• Database backups are encrypted at rest by Appwrite.
• Logs containing identifiers (email, tenantId) are not retained beyond 30 days.

Stampify cannot read your email. The architecture forbids it: the OAuth scopes Stampify holds do not grant mailbox access on either vendor. The add-ins only writeto the active compose body via the host's signature insertion API.

Rendered signatures do not contain tracking pixels by default. If a tenant turns on click tracking for a specific template, that's explicit, opt-in, and disclosed in the per-template configuration; the admin sees what was turned on and when. The admin dashboard itself ships zero third-party scripts; we don't embed analytics, ad, or session-replay tags.

At onboarding the admin picks a deployment region. Tenant data and the vendor refresh tokens stay in that region for the lifetime of the tenant.

• EU region: Frankfurt-hosted Appwrite project, EU-resident render endpoint.
• US region: US-East Appwrite project, US-resident render endpoint.
• A region change is a tenant migration, not a setting toggle. Contact us if you need one.

Stampify offers a standard DPA based on the EU Standard Contractual Clauses (2021/914) module 2, with UK addendum where applicable. Subprocessors are listed in the DPA and changes are notified in advance.

A self-serve PDF download lands when SOC 2 Type I is in flight. Until then, countersigned DPAs are issued by email so we can match the signing parties correctly.

If you believe you've found a security issue in Stampify, email security@cyberitex.com. We acknowledge inside one business day. Coordinated disclosure preferred. We don't run a public bug bounty yet; rewards for material findings are negotiated case by case.