Privacy Policy

Last updated: 29 May 2026

1. Overview

Autonodal is a signal intelligence platform that builds proximity graphs from your professional network and surfaces market feeds so you can act on what matters. This policy explains how we collect, process, and protect your data.

2. Data We Collect

When you use Autonodal, we collect the following categories of information:

• Account data — name, email address, authentication credentials
• Profile data — job title, company, professional context you provide
• Connection metadata — who you communicate with and how frequently (derived from email metadata and calendar events, with full bodies never stored)
• Interaction metadata — timestamps, frequency patterns, communication channels
• Signals — RSS feeds, market data, and curated intelligence you subscribe to

3. Gmail Data — Metadata Only

When you connect your Gmail account, Autonodal extracts proximity signals from message metadata. The OAuth scope we request (gmail.metadata) physically disallows the platform from reading message body content. Specifically, we read and store:

• WHO — sender and recipient email addresses (From, To, Cc headers)
• WHEN — message timestamps
• HOW OFTEN — frequency, recency, and reciprocity of communication
• SUBJECT LINE — stored for at-a-glance context on the interaction in your own sandbox

4. Google Contacts Data

When you connect Google Contacts, we access:

• Contact names, email addresses, phone numbers where available
• Company and job title information

Contacts are stored only within your own private Autonodal sandbox and are never shared with other Autonodal users or tenants.

5. Google Calendar Data

When you connect Google Calendar, we access:

• Event titles (used as an interaction subject in your proximity graph)
• Attendee email addresses
• Start and end timestamps

6. The Proximity-Only Model

Autonodal operates on a proximity-only extraction model for Gmail and Calendar. We read structured metadata to build mathematical relationship scores. The output is a set of proximity_scores that represent the strength and recency of your professional connections — not the substance of your communications.

7. Huddle Collaboration

When you join a Huddle (collaborative workspace), the following applies:

• Only proximity strength scores are shared with other Huddle members
• The source_platform of a connection is never exposed to other users
• You can detach from any Huddle at any time, cleanly removing your contributed data

8. Data Sharing and Processors

We do not sell your data. We do not use your data for advertising. We do not share your data with third parties for their marketing purposes.

We use the following infrastructure providers to operate the platform, each under a binding data processing agreement. This list is aligned with our published Data Processing Agreement Section 6 (Sub-processors).

• Railway Corp. (United States) — application hosting and primary database. International transfer governed by EU Standard Contractual Clauses (Commission Implementing Decision 2021/914, Module 3) plus supplementary measures including AES-256-GCM token encryption and PostgreSQL row-level security.
• Qdrant Solutions GmbH (Germany, EU; data hosted on GCP Frankfurt) — vector database for semantic search and metadata embeddings
• OpenAI, L.L.C. (United States) — generates mathematical vector embeddings used to power semantic search. OpenAI receives only the specific text submitted for embedding (public market signals, platform-generated person profiles, RSS content, and the Google-derived metadata fields listed in Section 9 — email subject lines and meeting titles only) and returns the corresponding vector. Under OpenAI's API Data Usage Policy, content submitted to the embeddings API is not used to train OpenAI's models and is not retained beyond the response. Message body content, attachments, event descriptions, attached documents, and meeting notes are not accessible to the platform (per the gmail.metadata scope constraint described in Section 9) and therefore are never transmitted to OpenAI or any other sub-processor.
• Anthropic, PBC (United States) — large-language-model inference (Claude) for platform features such as signal extraction from public content, dispatch generation, and the in-app Lorac assistant. Google user data is never transmitted to Anthropic. LinkedIn-sourced user data is never transmitted to Anthropic.
• Resend, Inc. (United States) — transactional email delivery (platform notifications only; no Google user data, no LinkedIn user data)
• Google LLC (United States) — OAuth identity infrastructure and the Google Workspace APIs (Gmail, Calendar, Contacts) the Tenant chooses to connect. Google’s processing of Tenant data via these APIs is governed by Google’s own terms; Autonodal’s use of the data once received is governed by Section 9 below.

9. How Autonodal Accesses, Uses, Stores, and Shares Google User Data

This section documents, in accordance with the Google API Services User Data Policy and the Limited Use requirements for Workspace APIs, how Autonodal interacts with data obtained from Google services.

Scopes Requested and Purpose of Access

Autonodal requests the following Google OAuth scopes, and each is used only for the purpose described:

• openid, https://www.googleapis.com/auth/userinfo.email, and https://www.googleapis.com/auth/userinfo.profile — Used solely to authenticate the user and associate the correct Autonodal account with their Google sign-in. The user's email address, name, and profile picture are stored to display their identity within the Autonodal interface.
• https://www.googleapis.com/auth/gmail.metadata — Used to read metadata from the user's sent and received email (From, To, Cc, timestamp, and subject line) in order to compute the user's professional network proximity graph within their own private Autonodal sandbox. The gmail.metadata scope is a narrower scope than gmail.readonly; it physically disallows the platform from accessing message body content, attachments, or the Gmail-generated message preview. Email metadata is processed to derive aggregate relationship metrics (frequency, recency, reciprocity) used exclusively for the user's own proximity scoring.
• https://www.googleapis.com/auth/contacts.readonly — Used to import the user's Google Contacts into their private Autonodal sandbox to seed their professional network graph. Contact data is stored only within the user's own tenant and is never shared across tenants or with other Autonodal users.
• https://www.googleapis.com/auth/calendar.readonly — Used to read the user's calendar event titles, attendee email addresses, and start/end timestamps in order to include meetings as interactions in the user's proximity graph. The calendar.readonly scope returns the full event object (including descriptions, locations, and attachment metadata); Autonodal’s ingestion code extracts only the title, attendees, and timing fields listed above and discards the rest in-process. Event descriptions, locations, attached documents, and meeting notes are never stored, processed, or retained by Autonodal.

Autonodal requests the minimum scope necessary for each described purpose and does not use any scope for a purpose other than the one stated above.

How Google User Data Is Used

Google user data is used exclusively to provide the user-facing features of the Autonodal platform that the user has explicitly enabled. Specifically:

• Email metadata is used to compute relationship proximity scores within the user's own private sandbox.
• Calendar event metadata is used to register meetings as interactions in the user's proximity graph.
• Contact data is used to populate the user's own professional network graph within their sandbox.
• Profile and email address data is used to authenticate the user to the Autonodal platform.

Google user data is not used for:

• Advertising, remarketing, or ad targeting of any kind.
• Determining creditworthiness or for lending purposes.
• Any purpose unrelated to the explicit user-facing features of Autonodal.
• Cross-tenant data aggregation, analysis, or correlation.

How Google User Data Is Stored

Google user data is stored in Autonodal's infrastructure on Railway (United States, primary application database) and, for derived proximity scores only, on Qdrant Cloud (European Union, GCP Frankfurt). OAuth access and refresh tokens are additionally encrypted at the application layer using AES-256-GCM before being written to the database. Access to each user's Google-derived data is scoped to that user's tenant sandbox and enforced by PostgreSQL row-level security policies; no other Autonodal user can access another user's Google-derived data.

Raw email message bodies are never stored, processed, or transmitted. Only the metadata and proximity metrics described above are retained.

How Google User Data Is Shared

Autonodal does not sell, transfer, or share Google user data with third parties except as strictly necessary to provide the Autonodal service to the user, and only with the following processors under binding data processing agreements:

• Railway (United States) — application and database hosting
• Qdrant Cloud (European Union, GCP Frankfurt) — vector storage for derived proximity scores and metadata embeddings
• OpenAI (United States) — generates vector embeddings of Google metadata (email subject lines and meeting titles only) to power semantic search within the user's own sandbox. Under OpenAI's API Data Usage Policy, content submitted to the embeddings API is not used to train OpenAI's models and is not retained beyond the response.

Google user data is never shared with, or sold to, advertisers, data brokers, or AI model training programmes. Email subject lines and meeting titles are transmitted to OpenAI solely for the purpose of generating vector embeddings as described above. Message content, attachments, event descriptions, attached documents, and meeting notes are never transmitted to OpenAI or any other third-party AI or machine-learning service.

AI/ML Model Training Disclosure

Autonodal does not use Google user data to develop, improve, or train generalised AI or machine-learning models. No Google user data is used to train, fine-tune, or improve any AI or machine-learning model, internal or external, under any circumstances. The use of OpenAI to generate embeddings of email subject lines and meeting titles (disclosed above) is a stateless API call under OpenAI's no-training, no-retention API Data Usage Policy.

When Autonodal uses large language models for in-product features (such as dossier generation or chat assistance), those features operate only on non-Google data (such as public market signals and platform-generated content), and any such use is confined to serving the individual user's in-product requests within their own sandbox.

Data Retention and Deletion

Google user data is retained only for as long as the user maintains an active Autonodal account and has not disconnected the relevant Google integration. Users may:

• Disconnect the Google integration at any time from the Autonodal settings page. Disconnection immediately revokes Autonodal's access at Google, deletes the stored OAuth tokens, and schedules deletion of all previously-retrieved Google user data within thirty (30) days.
• Revoke access directly via their Google Account at myaccount.google.com/permissions.
• Request full account deletion by emailing privacy@autonodal.com, which results in deletion of all user data, including all Google-derived data, within thirty (30) days.

Limited Use Compliance

Autonodal's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically, Autonodal:

• Uses access to, and use of, Google user data only to provide or improve user-facing features that are prominent in Autonodal's application interface.
• Does not transfer Google user data except as necessary to provide or improve user-facing features, and only to the service providers listed above under binding confidentiality and data processing terms.
• Does not use Google user data for serving advertisements.
• Does not allow humans to read Google user data except as required by law, with the user's affirmative agreement, for security purposes, or to perform aggregate, anonymised operations.

10. LinkedIn Sign-In

When you sign in to Autonodal with LinkedIn, we request the following OpenID Connect scopes from LinkedIn:

• openid — to receive a stable LinkedIn identifier
• profile — to display your name, profile picture, and locale within Autonodal
• email — to link your LinkedIn identity to your Autonodal account via your email address

LinkedIn sign-in provides identity only. The data accessed via these scopes is limited to your public profile and verified email. Autonodal does not access your LinkedIn connections, messages, activity, or content through this sign-in method.

To import your LinkedIn professional network into Autonodal you have two paths, both requiring explicit additional consent beyond sign-in:

• Manual data export (all users, all geographies) — download your LinkedIn data export from LinkedIn settings and upload the CSV files to Autonodal. We import connections, messages, and any other content you choose to include.
• Continuous DMA Portability API (EU/EEA/Switzerland members only) — under the EU Digital Markets Act, you may authorise Autonodal to fetch your LinkedIn data directly via LinkedIn's Member Data Portability (3rd Party) API. This is a one-click OAuth consent that replaces the manual export flow with live ingestion.

When you authorise the DMA Portability path, Autonodal requests the r_dma_portability_3rd_party scope. The version of this integration available at the date of this Policy fetches the following data (the “v1 scope”):

• Your connections list — name, current company, current title, profile URL — to map your professional network
• Your posts, comments, and reactions — fetched via ongoing daily polling of the LinkedIn Member Changelog API and accumulated within your tenant from the date you grant consent forward. The Changelog API itself exposes a rolling 28-day window of events; Autonodal retains each polled event from consent date onward. Used to detect topic interests and engagement patterns.
• Your profile fields — name, headline, current position — to keep your Autonodal profile in sync. We do not currently fetch your LinkedIn profile photo via this scope.

The v1 scope does not include your LinkedIn direct messages (DMs). DM ingestion (metadata-only, for relationship-warmth scoring consistent with the metadata-only Gmail processing described in Section 3) is a planned future capability and, when added, will require a separate explicit consent step and a Policy update.

Autonodal does not fetch your LinkedIn search history, your connections’ private profile details beyond what you can see in LinkedIn, or LinkedIn Recruiter / Talent Solutions data.

LinkedIn-sourced data and third-party AI providers. LinkedIn data obtained via the DMA Portability path is held within your tenant sandbox for use by the platform’s in-tenant features only. Autonodal does not transmit LinkedIn-sourced data to OpenAI, Anthropic, Google’s generative AI products, or any other third-party AI or machine-learning provider for embedding generation, model training, or inference. Topic-interest and proximity analysis on LinkedIn-derived content is performed within the tenant’s own data plane.

All DMA-Portability-sourced data is stored within your tenant-scoped database with Row-Level Security enforced; OAuth tokens are encrypted at rest with AES-256-GCM. Application data is hosted by Railway (United States) under the EU Standard Contractual Clauses (Module 3) plus supplementary measures; vector representations used for in-tenant semantic search are hosted by Qdrant Cloud in Frankfurt, EU. See our Data Processing Agreement Sections 6–7 for the complete international-transfer disclosure. Per LinkedIn’s DMA terms, your consent expires after 12 months and you will be prompted to re-authorise. You can revoke consent at any time from Autonodal Settings → Integrations → Disconnect LinkedIn, or from LinkedIn directly. On revocation, all LinkedIn-sourced data is deleted from your tenant within 24 hours.

LinkedIn sign-in data (your LinkedIn identifier and the email address linked to it) is retained only while you maintain an active Autonodal account. To revoke LinkedIn access, visit linkedin.com/psettings/permitted-services.

11. Data Retention and Deletion

You may delete your account at any time from your account settings. Upon deletion:

• All personal data is marked for deletion immediately
• Data is permanently and irrecoverably deleted within 30 days
• Aggregated, anonymised statistics may be retained but cannot be linked back to you

You can also request deletion by emailing privacy@autonodal.com.

12. Contact

For any privacy-related questions or requests, including questions about this Google user data disclosure, contact:

privacy@autonodal.com

13. Recent Changes

This section records substantive changes to how the platform handles Google user data so users can see, in plain language, how the architectural posture has tightened over time.

29 May 2026 — Gmail scope narrowed to gmail.metadata

The platform’s Gmail OAuth scope was narrowed from gmail.readonly (which technically permits body access) to gmail.metadata (which physically disallows it). The platform has always been architecturally proximity-only for users — processing relationship metadata, never message bodies — but this change moves that constraint from a policy promise to a constraint enforced by Google’s OAuth layer itself.

Two paths that had previously fetched email body content for non-user-facing reasons were retired as part of this change:

• Full-email intelligence mining — a developer-mode capability that was never exposed to users via any setting, toggle, or interface. The operator’s own account was the only account this had ever been enabled on. The capability has been retired; any body content previously captured to the operator’s account has been deleted from both the application database and the semantic-search vector store.
• Newsletter body capture — an automatic background process that previously fetched the body of certain newsletter-pattern senders (e.g. Substack publications, industry digests) on every Gmail sync. The body content was used as an input to the platform’s public-content signal extraction pipeline, contributing to the user’s signal feed. This path has been removed; newsletter content is now ingested only via direct RSS and publisher feeds, never via Gmail.

If your existing Gmail connection was granted before 29 May 2026, you will be prompted to reapprove on next visit with a one-line notice (“We’ve narrowed what we ask for; please reapprove with the new metadata-only access”). Reapproval is a single click and returns you to where you were — no re-onboarding.

14. Last Updated

This policy was last updated on 29 May 2026.