Privacy Policy

1. Who we are

Known is the operating brand of KnownIntel, Inc., a Delaware corporation. Our marketing site is knownintel.com; the product runs at app.knownintel.com.

Known builds institutional memory for revenue teams. We synthesize a customer’s own sales communications — emails, call transcripts, CRM updates — into a living account record their team can use through rep transitions and handoffs.

Contact: hello@knownintel.com

Who this policy covers. This policy describes how Known handles data on behalf of our enterprise customers. The data we process is, in nearly every case, the customer’s data — emails sent and received by their employees, transcripts of their meetings, records from their CRM. We process it as a data processor under the customer’s direction.

2. What data Known accesses, and why

Known connects to Google Workspace to power two capabilities, and the OAuth scopes below serve them:

• Account-context synthesis (read-only): for revenue teams, Known reads email, Meet transcripts, and calendar events involving customer-designated account domains and synthesizes a per-account context record. This capability is strictly read-only and domain-scoped (see §3).
• Lloyd, the personal assistant (read and write): operating only on the signed-in user’s own mailbox and calendar, Lloyd triages the user’s inbox, drafts and sends email the user composes or approves, and reads and manages the user’s calendar. Lloyd never reads another person’s mailbox or acts on anyone’s behalf but the connecting user’s.

Each scope is requested for a specific purpose, used for a specific thing, and explicitly not used for other things. Write scopes are requested only for Lloyd and only ever exercise on the connecting user’s own account.

Limited Use of Google user data

Known’s use and transfer to any other application of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Specifically: we use Google Workspace data only to provide and improve the user-facing features described in this section; we do not transfer it to others except as necessary to provide or improve those features, to comply with applicable law, or as part of a merger or acquisition; we do not use it for serving advertising of any kind; and no human at Known reads this data except with the user’s explicit consent, where necessary for security purposes or to comply with applicable law, or on data that has been aggregated and anonymized. Where synthesis is performed by our LLM subprocessor (Anthropic, PBC), the data is sent solely to generate the user-facing account synthesis under a data-processing agreement and is never used to train shared models.

gmail.readonly — read email

• Why we need it. For account-context synthesis, to read email between the customer’s employees and in-scope account contacts. For Lloyd, to read the signed-in user’s own inbox so the assistant can triage it, summarize threads, and surface what needs attention.
• What we do with it. We extract structured facts (for accounts) or build the user’s own assistant view (for Lloyd), each linked back to the specific email it came from.
• What we do not do with it. We do not use email content to train shared models. In the account-context capability we do not ingest out-of-scope or internal-only email (§3); in Lloyd we read only the connecting user’s own mailbox.

gmail.send — send email (Lloyd only)

• Why we need it. Lloyd drafts replies and messages and sends them from the user’s own account, at the user’s direction — the assistant’s core “handle this for me” action.
• What we do not do with it. We do not send on anyone’s behalf but the connecting user’s. We do not send bulk or marketing mail. We do not send without the user composing or approving the message.

gmail.modify — triage labels & state (Lloyd only)

• Why we need it. Inbox triage: at the user’s direction Lloyd archives, labels, and marks read/unread the user’s own messages. modify is the narrowest scope that covers label and read-state changes.
• What we do not do with it. We do not permanently delete mail, and we act only on the connecting user’s own mailbox.

meetings.space.readonly — Meet transcripts

• Why we need it. We read Google Meet meeting transcripts via the Google Meet API to incorporate meeting commitments and notes.
• What we do not do with it. We do not enumerate the user’s entire Drive or read documents that are not Meet transcripts.

calendar.events.readonly / calendar.calendarlist.readonly — read calendar

• Why we need them. To read events (meeting times, attendees, titles) for meeting-aware context and Lloyd’s schedule view, and to list the user’s calendars so they can choose which one Lloyd reads and writes.
• What we do not do with them. In the account capability we ingest only events with an external in-scope attendee (§3); we do not aggregate calendar data across customers.

calendar.events — create/modify events (Lloyd only)

• Why we need it. At the user’s direction, Lloyd places calendar holds and creates or reschedules events on the user’s own calendar (e.g. “block 2pm Thursday”).
• What we do not do with it. We write only to the connecting user’s own calendar and only at their direction.

userinfo.email / userinfo.profile / openid — identity

• Why we need them. To identify the connecting Google account at sign-in / connection time. We do not use the user’s address for marketing without separate consent.

3. Scope boundaries

The two capabilities have different — and equally strict — boundaries.

Lloyd (personal assistant) operates on only the signed-in user’s own mailbox and calendar. It is not a multi-user or team-monitoring surface: Lloyd never reads another person’s mailbox, never aggregates one user’s activity for another, and every write (send, label, calendar) lands only on the connecting user’s own account at their direction.

Account-context synthesis only ingests communications that involve customer-designated in-scope account domains, and is read-only:

• The customer’s administrator designates which external email domains correspond to which customer accounts. Only emails where the sender or recipient domain matches a designated in-scope domain are ingested.
• Internal-only emails — where both the sender and every recipient are on the customer’s own domain — are excluded by the connector and never reach our systems. Internal coordination, HR, finance, and any other internal communication is invisible to Known.
• Emails involving domains that are not designated in-scope are not ingested, not stored, and not processed.

Domain scoping is enforced at the connector layer, not as a downstream filter. An email outside scope never reaches our storage.

4. Where data is stored, and how it’s protected

Known operates to a SOC 2 Type 2 posture. The SOC 2 attestation is in progress; the controls are in place from day one.

• Encryption at rest. All customer data is encrypted at rest using AES-256.
• Encryption in transit. All data is encrypted in transit using TLS 1.2 or higher.
• Key management. Encryption keys are managed in a KMS with regular rotation, scoped per tenant. A key compromise on one tenant cannot expose another.
• Tenant isolation. Every record is tagged with a tenant identifier. Cross-tenant reads are refused at the repository boundary.
• Access controls. Every action that touches customer data is authenticated, authorized, and logged. RBAC is enforced at the API layer, not just the UI. There are two production paths to customer data: the Salesforce-native modal (Salesforce SSO) and the authenticated Known web app (Google Workspace SSO at launch). External recipients use single-recipient email-bound magic-link invites that are themselves audit-logged. There are no unauthenticated public routes to customer data.
• Production access. Personnel access to production systems requires MFA, is logged, and is reviewed. No shared accounts. No long-lived credentials in source control.

5. How long data is kept

• Raw email and transcript bodies. Purged on a 90-day rolling window by a deletion job. After 90 days, the raw body is gone from Known’s systems.
• Source metadata. A lightweight per-event record (event identifier, type, date, participants, a short snippet) is retained longer than the raw body, so the audit trail outlives the raw-content purge.
• Synthesized summaries. Retained for the lifetime of the customer relationship plus the audit retention period.
• User corrections. Retained indefinitely as a training signal for improving synthesis on the customer’s accounts.
• Audit logs. Retained for the SOC 2 audit retention period.

When a customer terminates, or asks for deletion, all of the above are deleted end-to-end — primary stores, backups, and subprocessor caches — within 30 days.

6. Who we share data with

Known uses a small set of third-party subprocessors to deliver the service. We publish the list. We never sell customer data, and we do not share customer data with any other Known customer.

The full subprocessor list — including DPA status and the change-notification process — is published at knownintel.com/legal/subprocessors.

Active subprocessors at the date of this policy are Anthropic, PBC (LLM provider for synthesis), Google LLC (source systems, customer-granted), Google Cloud Platform (the infrastructure Known runs on — the web application, its API, its scheduled jobs, the AI-assistant connector, and the production database, in the United States), Cloudflare, Inc. (authoritative DNS for the knownintel.com domain and hosting for the public marketing site — the application hostnames resolve directly to Google Cloud, so no customer data passes through Cloudflare), Resend (transactional email — invites and one-time sign-in codes), Stripe, Inc. (subscription billing — card details go to Stripe directly and never pass through Known), and GitHub, Inc. (code hosting, not in the customer-data path).

Google Cloud Platform. Known runs on Google Cloud (Cloud Run and Cloud SQL, in the United States): the web application, its API, its scheduled jobs, the AI-assistant connector, and the database your data rests in. Google holds this role as Known’s own infrastructure provider, engaged directly by Known — a different relationship from the Google LLC entry above, where Gmail and Drive are your source systems under your Google agreement. Until 2026-08 this role was held by Cloudflare; that migration completed on 2026-08-18, and Cloudflare now provides only domain-name service for knownintel.com and hosting for the public marketing site.

One disclosure about that move. The previous version of this policy said Known would not process customer data on Google Cloud until its data-processing agreement with Google was executed and the notice period below had run. The migration completed before both of those steps were finished. The agreement is being put in place, and we are recording the sequence here rather than quietly dropping the commitment. No customer was under contract at the time of the move.

We add subprocessors only when they are needed to deliver the service. When we add one, we update the list and notify customers per their DPA. The standard notice period is 30 days before the new subprocessor begins processing customer data.

No sale of customer data. Known does not sell customer data. Not to advertisers, not to data brokers, not to anyone.

7. AI processing

Known’s synthesis layer is powered by large language models. This produces the headlines, stakeholder notes, sentiment signals, and commitment extractions the customer sees in the product.

• What gets sent. Customer email and transcript content is sent to the Anthropic API. No other LLM provider is used.
• What Anthropic does with it. Anthropic processes the data to return Known’s structured output, under Anthropic’s published data-processing terms. Anthropic does not train its public models on data sent via the API.
• Source attribution. Every claim Known displays in the product is tied back, in the user interface, to the source events that produced it — emails, transcript timestamps, CRM updates — so any user can ask “where did this claim come from?” and get a list of receipts in one click. This is a hard requirement of how Known is built, not a feature we plan to add later.
• No shared model training. Known does not train shared, cross-customer models on customer-identifiable content.

8. Customer rights

The data Known holds about a customer’s account communications is the customer’s data. The customer can, at any time:

• Request a copy of the data Known holds for them, in a machine-readable format.
• Request deletion of the data Known holds for them. Deletion completes end-to-end — primary stores, backups, and subprocessor caches — within 30 days of request.
• Revoke OAuth access from Google Workspace (or any other connected source system) at any time. Revocation immediately stops all further ingestion.
• Request a full access log for their tenant. Every read of customer data is auditable; the customer can pull their complete access log on demand.

9. Audit access

Every read of customer data in the Known production product is recorded in an audit log. The log records the actor (which user or system), the action, the resource (which tenant and account), the source IP and user-agent, and a timestamp. Token-bound access from magic-link invites is logged the same way: the audit trail attributes the read to the invited email address.

The audit log is tenant-isolated. A customer can request and receive their full audit log on demand.

10. International users and GDPR posture

Known is a US company serving primarily US enterprise customers at launch. Regardless of customer location, Known operates to a GDPR-aligned standard on the parts of GDPR that matter most in practice:

• Right to deletion. 30 days, end-to-end, as described in §8.
• Data minimization. Raw content is purged on a 90-day rolling window. Only synthesized output is retained long-term.
• Processor disclosure. Subprocessors are listed (§6) and customers are notified before new ones are added.
• Purpose limitation. Data is processed only for the purpose of delivering Known’s service to the customer who supplied it.

11. Children’s data

Known is a B2B product for enterprise revenue teams. We do not knowingly collect data from anyone under 18. If a customer’s data inadvertently includes a minor’s information and the customer notifies us, we will delete it on the same timeline as any other deletion request.

12. Changes to this policy

Known will update this policy as the product, vendor stack, or regulatory posture changes. Every version carries an effective date and a version number.

Material changes — changes that meaningfully alter what data is collected, who has access to it, how long it’s kept, or which subprocessors are involved — will be communicated to customers at least 30 days before they take effect.

13. Contact

For privacy questions, data subject requests, or any of the rights described in §8 above, contact us at hello@knownintel.com.

Known is an operating brand of KnownIntel, Inc. © 2026 KnownIntel, Inc. All rights reserved.