Data Processing Agreement

2026-04-12-e15769e

Purpose and Scope

This Data Processing Agreement ("DPA") forms part of the agreement between the Customer ("Controller") and ShareGuard, Inc. ("Processor") for the provision of ShareGuard's security proxy services between AI assistants and Google Workspace ("Services").

This DPA governs the Processor's processing of Personal Data on behalf of the Controller and sets out the parties' respective obligations under applicable data protection laws.

1. Definitions

• Personal Data — any information relating to an identified or identifiable natural person processed through the Services.
• Processing — any operation performed on Personal Data, including collection, access, retrieval, transmission, or deletion.
• Controller — the Customer, who determines the purposes and means of processing Personal Data.
• Processor — ShareGuard, which processes Personal Data on behalf of the Controller.
• Sub-processor — any third party engaged by ShareGuard to process Personal Data on behalf of the Controller.
• Data Subject — the individual whose Personal Data is processed.

2. Role and Responsibilities

ShareGuard acts as a Processor on behalf of the Controller. ShareGuard does not determine the purposes or means of processing Personal Data and processes Personal Data solely in accordance with the Controller's documented instructions, which are expressed through organization-level permission configurations, per-user and per-file access policies, and audit and compliance settings configured in the ShareGuard administrative dashboard.

2.1 Data Flow

1. An AI assistant (e.g., Anthropic Claude) requests access to a Google Workspace file through the ShareGuard MCP endpoint.
2. ShareGuard evaluates the request against the Controller's organization and user-level permission policies.
3. If the request is allowed, ShareGuard proxies the request to Google Workspace using the end user's own OAuth credentials (drive.file scope).
4. Google Workspace returns the requested data directly through ShareGuard, which forwards it to the AI session without caching or persisting file contents.
5. ShareGuard records an audit log entry describing the action, the user, the file identifier (hashed), timestamps, byte counts, and outcome.

3. Data Storage and Retention

3.1 File Contents — Never Stored

ShareGuard is a pass-through proxy. File contents (the body of Google Docs, Sheets, Slides, and other files) are never cached, persisted, indexed, or retained in any form. Every file read hits Google Workspace directly and the response is forwarded to the AI session in-memory only.

3.2 Metadata Stored

ShareGuard stores the following metadata to enforce policies, provide audit capability, and operate the service:

3.3 Categories of Data Subjects

The Personal Data processed through ShareGuard relates to: the Controller's employees, contractors, and authorized users who access Google Workspace through an AI assistant; and individuals whose Personal Data appears in those Google Workspace files (incidentally, via transient pass-through — ShareGuard does not inspect, index, or retain this content).

4. Security Measures

ShareGuard implements technical and organizational measures designed to protect Personal Data against unauthorized or unlawful processing, accidental loss, destruction, or damage.

4.1 Encryption

• In transit: All connections to ShareGuard require TLS 1.2 or higher. Connections to Google Workspace APIs use Google's standard TLS configuration. Connections from ShareGuard to Cloud SQL use encrypted Unix sockets.
• At rest: Cloud SQL databases are encrypted at rest using Google-managed encryption keys (AES-256). Secret Manager contents are encrypted at rest by Google-managed keys. OAuth refresh tokens are stored exclusively in Secret Manager, never in the application database.

4.2 Authentication and Access Control

• All user authentication flows through Firebase Identity Platform with optional organization-scoped tenants.
• AI assistant access uses OAuth 2.0 with PKCE (RFC 7636), dynamic client registration (RFC 7591), and refresh token rotation with replay detection.
• Access tokens rotate every hour; a token family is revoked on detected replay outside the rotation grace window.
• Access to Google Workspace uses the end user's own OAuth credentials at the drive.file scope, ensuring ShareGuard can only see files the user explicitly shared.
• Tool-level permissions are enforced with an org → group → user chain; the most specific deny wins.

4.3 Network Security

• All services run on Google Cloud Run in the us-central1 region with IAM-enforced access controls.
• A Google Cloud Armor WAF filters traffic to the API, with logging enabled on all rules.
• Service-to-service authentication uses Google Cloud IAM and Workload Identity Federation; long-lived service account keys are not used.

4.4 Application-Layer Controls

• Kill switch: Controllers may disable all AI access organization-wide with a single action.
• Per-user sharing disable: Administrators may disable AI access for individual users without removing their account.
• File blocking: Users or administrators may revoke ShareGuard's access to individual files; subsequent access attempts are logged and denied.
• File read-only mode: Files may be marked read-only at the proxy layer, independent of Google Drive permissions.
• DLP scanning: Optional content scanning via Google Cloud DLP with configurable info types and custom patterns; block or audit mode.
• Risk-based session enforcement: Administrators configure automated responses to Google security events (session revoked, token revoked, account disabled).

4.5 Operational Security

• All ShareGuard personnel with production access are bound by confidentiality obligations.
• Deployments are automated via GitHub Actions using Workload Identity Federation; no long-lived deploy credentials exist.
• Infrastructure is defined as code (OpenTofu); changes are reviewed before deployment.
• Code changes are reviewed before merge to the main branch.

5. Audit Logging

ShareGuard maintains comprehensive audit logs of every operation performed through the Services. Each audit entry records:

• The action performed (tool name, e.g., read_file, update_document)
• The user who initiated it (internal user ID, mapped to email in the dashboard)
• The resource affected (hashed file ID plus human-readable name where known)
• Timestamp, duration, and bytes transferred
• Client information (IP address, user agent, client classification)
• Session identifier (partial, for correlation without exposing credentials)
• Status code and any error message
• Permission decision metadata (which policy allowed or denied the action)

5.1 SIEM Integration

Audit logs can be streamed in real-time to the Controller's SIEM platform through the ShareGuard Log Destinations feature. Supported destinations include Splunk HTTP Event Collector, Datadog, Elastic, and generic HTTPS webhooks. Audit events are delivered using a transactional outbox pattern, batched, HMAC-signed, and retried on failure to ensure at-least-once delivery.

5.2 Retention

Audit logs are retained for 365 days by default. Longer retention is available on request and subject to commercial terms.

6. Sub-processors

6.1 Current Sub-processors

6.2 Sub-processor Changes

ShareGuard shall notify the Controller of any intended changes to sub-processors by updating this DPA and providing at least 30 days advance notice via email to the Controller's designated contact, where the Controller has an opportunity to object. If the Controller objects to a new sub-processor on reasonable grounds, ShareGuard will work in good faith to provide an alternative or permit the Controller to terminate the affected Services.

7. Data Subject Rights

ShareGuard shall assist the Controller in responding to Data Subject requests under applicable law, including access, rectification, erasure, restriction, and portability. Because ShareGuard stores only metadata and audit records (not file contents), most Data Subject requests can be fulfilled from the ShareGuard administrative dashboard directly. For requests that require engineering assistance, ShareGuard will respond to Controller assistance requests within 72 hours of receipt.

8. Data Breach Notification

ShareGuard shall notify the Controller of any Personal Data breach affecting the Controller's data without undue delay, and in any event within 72 hours of becoming aware of the breach. Notification shall include:

• The nature of the breach and categories of data affected
• The approximate number of Data Subjects affected
• Likely consequences of the breach
• Measures taken or proposed to address the breach and mitigate adverse effects
• A named point of contact for follow-up

ShareGuard's incident response process includes automated monitoring of the audit logs and infrastructure for anomalies, with alerts routed to the on-call engineer.

9. Data Deletion and Return

Upon termination of the Services, ShareGuard shall, at the Controller's choice, delete or return all Personal Data processed on behalf of the Controller within 30 days.

Deletion includes: user records in the application database, audit logs, session records, secret material (OAuth refresh tokens, signing keys), and all backups within the normal backup retention cycle (backups beyond that cycle are deleted as they age out, typically within 35 days).

Return is available in a standard JSON export format through the administrative dashboard or by request to privacy@shareguard.ai.

10. International Data Transfers

ShareGuard is a United States company. All Personal Data is processed and stored in Google Cloud's us-central1 region (Council Bluffs, Iowa). Data is not routinely transferred outside the United States.

Customers with data residency requirements that exclude the United States should contact sales@shareguard.ai to discuss commercial options. For transfers to the United States from jurisdictions that require a transfer mechanism (such as EU Member States), the parties rely on the Standard Contractual Clauses adopted by the European Commission under Decision (EU) 2021/914, which are incorporated by reference into this DPA for such transfers.

11. Compliance Frameworks

ShareGuard's current and planned compliance posture:

• SOC 2 Type I: Readiness in progress. Target report: Q4 2026.
• SOC 2 Type II: Planned following Type I completion.
• GDPR: ShareGuard supports GDPR obligations as a Processor through the measures described in this DPA. This DPA serves as the Article 28 contract between Processor and Controller.
• CCPA/CPRA: ShareGuard processes Personal Data as a "Service Provider" under CCPA and shall not sell Personal Data or process it for any purpose other than performing the Services.
• HIPAA: ShareGuard is not currently a HIPAA Business Associate and does not recommend processing Protected Health Information through the Services at this time.

12. Term and Termination

This DPA shall remain in effect for the duration of ShareGuard's processing of Personal Data on behalf of the Controller. The obligations in this DPA shall survive termination to the extent required for ShareGuard to complete deletion or return of Personal Data in accordance with Section 9.

13. Governing Law

This DPA is governed by the laws of the State of Delaware, without regard to its conflict of laws principles. Any dispute arising out of or relating to this DPA shall be resolved in accordance with the dispute resolution provisions of the main Terms of Service.

14. Contact Information

For privacy and data protection inquiries, including Data Subject requests, breach notifications, and sub-processor objections:

• Email: privacy@shareguard.ai
• Company: SynapsiumLabs, Inc. (operating ShareGuard)

15. Changes to This DPA

ShareGuard may update this DPA from time to time to reflect changes in technical or organizational measures, sub-processors, or regulatory requirements. Each version of this DPA is permanently identified by a date-and-commit version string (visible at the top of this page) and is archived in the public ShareGuard marketing repository. Material changes will be communicated to Controllers via email at least 30 days before they take effect.