Email Integration Security Brief

SECURITY BRIEF

Stackpack Email Integrations

Gmail and Microsoft 365: Privacy, Access, and Data Handling

Updated October 14 2026  •  Stackpack, Inc.

Stackpack’s email integrations automatically identify and collect vendor contracts, invoices, and receipts from your organization’s email, enabling hands-free vendor document management. Two mail providers are supported: Google Gmail and Microsoft 365 (Outlook, through Microsoft Graph). Only emails determined to contain a relevant vendor document are ever collected; no other email content is accessed beyond the provider-side search used to find candidates.

Customer trust is foundational to everything we build at Stackpack. When you enable an email integration, you are trusting Stackpack with access to your business’s email. Both integrations were designed with this trust in mind: they share one pipeline with integration-specific controls that restrict our access to only what is necessary and protect your data at every stage. Where the two providers differ, this brief says so.

Product Overview

The email integrations are entirely automated. There is no human in the loop, at your organization or at Stackpack, in the vendor document matching process.

To operate, Stackpack periodically asks the connected provider for messages received since the last scan that match a short list of vendor-document indicators in the subject line or sender. The provider answers with message identifiers only; messages that do not match are never retrieved. For each candidate, Stackpack retrieves the message and runs it through a classifier that decides whether it is a vendor contract, invoice, or receipt. Candidates that are not vendor documents are discarded. Documents are matched to the correct vendor record in Stackpack and stored alongside it.

Stackpack’s Overall Security Posture

Stackpack maintains a SOC 2 Type II report, providing independent third-party validation that our security program meets industry standards to keep your data protected. This report is updated on an annual basis and is available to customers upon request. Our full list of current compliance certifications and supporting documentation is available at trust.stackpack.ai.

Threat Model

Two primary attack vectors informed the design of Stackpack’s email integrations:

• Compromise of account access: If the credential Stackpack uses to reach your mail provider were compromised, an attacker could read email within the scope of the integration.

• Compromise of Stackpack’s storage or admin systems: If Stackpack itself were compromised, an attacker could access information stored in Stackpack’s systems, including any retained email content.

To mitigate these risks, Stackpack designed the integrations to: minimize the data accessed at every stage; avoid storing information we do not need; and robustly protect the data and credentials that we do store. The sections below detail these mitigations.

Mitigations

Access to Your Inboxes

Both integrations use the provider’s official mechanism for an organization administrator to grant an application access to mailboxes, without each employee consenting individually. In both cases Stackpack interacts with your mail exclusively through the provider’s APIs over encrypted connections, with read-only permission, and only for the mailboxes your administrator adds in Stackpack.

Credentials for the service account and the app registration are available to only a small number of engineers actively maintaining the integrations.

A note on Microsoft 365: the permission a Global Administrator grants is tenant-wide at Microsoft’s side. Stackpack only ever reads the mailboxes an administrator adds in Stackpack, and checks that it can read each mailbox at the moment it is added. Organizations that want this boundary enforced by Microsoft as well can scope the application with Exchange Online role-based access control for applications.

Opting Out Inboxes and Revoking Access

Stackpack gives you full control over which inboxes we access.

By default, Stackpack queries only inboxes that have an associated active Stackpack account and that an administrator has added to the integration. We never attempt to access inboxes without a corresponding, selected Stackpack user.

In-app control: Individual user inboxes are read only while selected on the agent settings page in the Stackpack App. When a user is removed from the list, Stackpack does not attempt to access email metadata or message bodies for their inbox.

Admin revocation: Stackpack administrators can disconnect an integration for all users in their organization from the agent settings page. To fully revoke access, administrators should also remove Stackpack at the provider, as described in the table above.

Minimizing Data Processed

The integrations are designed to minimize the data processed at every step.

The first filter runs at the provider. Stackpack searches a connected inbox for messages received since the last scan whose subject line or sender matches a short list of vendor-document indicators, such as invoice, receipt, contract, or billing. The provider returns message identifiers only; messages that do not match are never retrieved, and Stackpack never sees their headers or content. Junk and deleted mail are excluded from the search.

For each candidate, Stackpack retrieves the message, including its headers, body, and the names of its attachments, and a classifier decides whether it is a vendor contract, invoice, or receipt. The classifier is given the headers, the attachment names, and the first 16,000 characters of the readable body text, which is the entire body for all but the longest messages. Candidates that are not vendor documents are discarded. Attachments themselves are downloaded only for messages the classifier has accepted, and only up to a size limit.

Accepted documents are processed by Stackpack’s document-matching system, the same system used for vendor documents submitted manually through Stackpack’s document intake.

Minimizing Data Stored

Stackpack avoids storing data that is not necessary and deletes data after it is no longer needed. For each email processed, Stackpack potentially stores three categories of information:

The message identifier is the provider’s own: Gmail’s message id, or Microsoft Graph’s immutable message id. Neither reveals anything about the message’s content.

Vendor documents sent to Stackpack’s document-processing system are retained for a period consistent with how documents submitted via other intake methods are handled.

Stackpack regularly snapshots and backs up our databases for service availability. Database snapshots and backups are deleted after 30 days in standard cases, and may be retained for up to six months. They are encrypted in transit and at rest.

Protecting Stored Data

All data retrieved by the email integrations is encrypted at rest in our database and file storage systems. The database used for email integration data uses a separate set of encryption keys from Stackpack’s other databases. Sensitive information stored within it, such as message subjects and headers, is additionally encrypted at the row level.

Access to integration data is not generally available to internal systems or to Stackpack personnel through any application, including internal administration tools.

Vendor documents sent to Stackpack’s document-processing system are also encrypted at rest and treated identically to documents submitted via other intake methods.

Stackpack’s platform, including all systems that process and store data for the email integrations, runs on Google Cloud. Following the principle of least privilege, only engineers actively maintaining these integrations have access to related databases and infrastructure.

Adding Providers

Both integrations run on one provider-neutral pipeline: a connector reads a mailbox through the provider’s API, and everything after that, classification, matching, storage, and retention, is shared. A new mail provider is a new connector with its own entry in the access table above; the mitigations in the rest of this brief apply to it unchanged. This brief will be updated when a provider is added.

Questions and Contact

For security-related questions about these integrations, please contact: