Attio data access and security

We request only the permissions needed to do the job — and nothing more. This article explains exactly what data we access, what we store, and what we never touch.

Written By Kevin Lawrie

Last updated About 6 hours ago

Our approach to data access

Minimal data access, by design. We interact with only what's needed to do the job and nothing more. No bulk sync, no mirroring of your person records, no retention of data we don't need.

  • We store only the internal Attio record ID and LinkedIn username (public data) for records we create or monitor. No personal attributes are retained.

  • Duplicate checks read your LinkedIn username and email fields — we don't retain that data. It's a read-only exercise.

  • We never replicate your contact database.

  • Integration audit logs are automatically rotated every 30 days.

  • Read access for configuration is limited to list names, internal IDs, and attribute schema — never person record content.

OAuth scopes we request

When you connect Attio, you'll see a permissions screen on Attio's authorisation page. Here's what each permission is used for:

Capability

What we use it for

Record read / search

Look up people by LinkedIn URL or email to detect duplicates before creating new records

Record write

Create new people and update existing ones when Signal Sync runs

List membership read

Read your Attio Lists so you can select which list to sync from

List membership write

Add new people to a selected Attio list when Signal Sync creates them

Notes / activities write

Create notes on Person Records for social engagement activity

Attribute schema read

Read your person attribute schema so you can configure field mapping

We do not request write access to your attribute schema, access to deals or other Attio objects, or any permissions beyond what's listed above.

What we store — by mode

Mode 1 — Creating records from engagement (Signal Sync)

When we turn a reaction or comment into an Attio person, our READ access is used only to detect duplicates. We check the LinkedIn username attribute and the email attribute — only if you have Email Finder enabled and we have an email to compare. In both cases we don't retain that data. It's a read-only exercise.

The only data points we store are:

  • The internal Attio record ID created when we generate a person record

  • The Note ID for any notes we create representing social engagement

These are internal CRM identifiers and contain no personal data.

Mode 2 — Syncing existing records or monitoring job changes (Engagement Sync)

When you create an Attio List and sync it, we READ the LinkedIn username attribute and the person record's internal Attio ID, saving both to our system. This relationship is what allows us to sync notes back to the correct person every time that LinkedIn username publishes a post, likes a post, or comments.

We also retain the internal ID of each note we create — primarily for audit purposes, so you can always see every action we've taken inside your CRM.

Read access for configuration

We fetch your available Attio Lists (name and internal ID only) so you can select which list to sync from or add new people to. We also read your person attribute schema to configure field mapping — specifying which enriched data fields get pushed to Attio and where they land.

Audit logs

All Attio integration activity is logged and visible in your account dashboard. Logs are automatically rotated every 30 days.

What we never do

  • Never bulk-sync or mirror your person record database

  • Never retain attribute values from your existing Attio records

  • Never store email addresses, phone numbers, or personal data from your existing people

  • Never access companies, deals, or any Attio object outside of people, lists, and notes

  • Never read person record content beyond what's needed for duplicate detection and matching