Airtable bases often hold customer lists, project plans and operational data that business teams build without IT, so share links, extensions and personal access tokens decide who outside the organisation can read that data. This guide covers the customer-side controls in Airtable: SSO and two-factor authentication, admin roles, share link and sync settings, extension and integration restrictions, personal access token scopes, service accounts, audit logging and a hardening baseline. It is written for Airtable admins, SaaS security teams and anyone reviewing an Airtable rollout, with most attention on Business and Enterprise Scale plans where the admin panel lives. If a token has already leaked, start with the Work SaaS API tokens response guide.
This is an independent guide from NHI Mgmt Group, based on Airtable's public documentation as of November 2026. It is not sponsored or reviewed by Airtable. Product features change, so confirm settings against Airtable's current documentation.
Key takeaways
- Set share links to the narrowest mode that works. The admin panel Share links setting offers Public, Flexible, Private and Members only, with an email domain allowlist; decide it before users publish views and forms.
- Require SSO, then test before you flip it. SSO is configured per verified domain and starts as optional; setting it to required signs every member out at once, so validate the IdP metadata first and plan an admin recovery path.
- Treat every personal access token as a user. A PAT can only do what its creator can do, and it carries scopes and base access; grant the fewest scopes and bases, and cap token lifetime with the enterprise policy.
- Move integrations to service accounts. On Enterprise Scale, service accounts are non-user accounts that cannot sign in to the UI, survive staff departures and carry their own scoped tokens.
- Pull the audit log into your SIEM. Audit events are kept for 180 days and the admin panel returns up to 10,000 events per search, so use the Audit Log Events API for continuous export.
How identity and access work in Airtable
Airtable separates sign-in (email and password, Google, or SAML SSO) from authorisation (workspace, base and interface collaborator permissions managed in Airtable). SSO decides who can sign in; licences and permissions stay in the admin panel. Security here is a shared responsibility: Airtable runs the service, and the customer decides who is invited, what is shared and which integrations can reach the data.
| Identity | How it authenticates | Customer control |
|---|---|---|
| Members on verified domains | SAML 2.0 SSO (optional or required per domain) or email and password | Email domains and SSO configuration; SSO required; Fixed Web Session length |
| External collaborators | Their own Airtable account, or your IdP after an email-confirmation linking step | Collaborator invites restricted to your domains |
| Share link viewers | Anonymous link, password or email domain login | Share links organisation setting and per-view link settings |
| Personal access tokens | Bearer token in the Authorization header | Scopes, base access, maximum lifetime, API allowlist |
| Service accounts | Personal access tokens or an OAuth authorisation, no UI sign-in | Created and scoped by admins on Enterprise Scale |
| OAuth integrations | Authorisation granted by a user to a third-party app | Block API access for third-party integrations, with an allowlist |
SSO and two-factor authentication
- Domains and SSO: Verify each domain under Email domains and SSO configuration, then set SSO to optional or required per federated domain. Airtable publishes setup guides for Okta, Google, OneLogin, Microsoft Entra ID and ADFS. Use the Email attribute (V2) option so a stable identifier such as an employee ID can sit in the SAML NameID while email stays a separate attribute.
- Required mode: Required redirects every other sign-in attempt to your IdP and immediately signs out all members on that domain. A wrong sign-in URL or certificate can lock out admins too. Airtable's documented recovery is a verified admin asking Airtable Support to set the domain back to optional; its documented workaround is a separate domain or subdomain without SSO for admin accounts. Our recommendation: keep one break-glass admin on such a domain, protected by two-factor authentication and monitored.
- Certificates: Track the IdP signing certificate expiry and rotate it before it lapses; switch SSO to optional before editing metadata.
- Two-factor authentication: On Enterprise Scale, set the enterprise two-factor requirement to on for members only, or on for all users who access enterprise content. The second option also covers external collaborators.
- Sessions and terms: Fixed Web Session length sets how long users stay signed in. Custom terms of use (Enterprise Scale) make users accept your terms before reaching organisation data.
- Provisioning: JIT creates an account on first SSO sign-in. SCIM creates accounts when access is granted in the IdP, with default integrations for Okta and Microsoft Entra ID; programmatic disable and reactivate through SCIM is supported for Okta. See the SCIM Provisioning Guide.
Availability: SSO and Fixed Web Session length are on Business and Enterprise Scale plans. Enterprise two-factor enforcement, custom terms, audit logs and service accounts are Enterprise Scale. IP range restrictions are listed for Enterprise Org. Confirm the current plan matrix in Airtable's documentation.
Admin roles and privileged access
Airtable provides predefined admin roles on Enterprise Scale, assigned under Roles, Assignees, + Assign in the admin panel. A user with several roles gets the combined permissions of all of them.
| Role | What it can do | Our guidance |
|---|---|---|
| Admin (Super admin in Enterprise Hub) | Full admin panel access, all users, workspaces and settings | Two or three named people plus one break-glass account |
| Org unit admin (Enterprise Hub) | Full admin panel access within assigned org units | Use for business units instead of granting Admin |
| User admin | Users, licences, groups and memberships; workspace, base and interface collaborations | Help desk and access teams |
| Integration admin | Integration settings, including HyperDB, and the Integrations and development settings | Platform or integration owners only; this role governs API and extension policy |
| Brand admin | Organisation branding and Org resources settings | Communications staff |
- Admin data access: Admins can use user role access on workspaces and bases where they are not direct collaborators, and a PAT an admin owns adopts those permissions. An admin's token is therefore an organisation-wide data token. Our recommendation: admins create integration tokens on service accounts, never on their own account.
- Review stacked roles: Export role assignees each quarter and remove combinations, such as User admin plus Integration admin, that let one person both grant access and open API policy.
- Delegation in Enterprise Hub: Turn on Prevent org unit admin edits so only super admins change the app and component allowlist, and set Org unit membership to admin review where onboarding needs a check.
Sharing, sync and extensions
Most Airtable data exposure is a sharing decision. Set the organisation-wide policy first, then teach builders the per-view options.
| Admin panel setting | Options | Our baseline |
|---|---|---|
| Share links | Public, Flexible, Private, Members only; email domain allowlist; Keep existing share links public; Allow unrestricted access to password-protected shares; Allow access to shared forms | Members only or Private, with forms allowed only where public intake is a business need |
| Collaborator invites | Unrestricted, restricted to your domains (allowlist), restricted to org unit members | Restricted to your domains, with partner domains added by request |
| Synced view restrictions | Unrestricted, Restricted (bases in your organisation), Off | Restricted; use Review share links to see sync counts |
| File attachments | Unrestricted, Restricted, Custom allow | Custom allow for the file types you need |
| Prevent public sharing of interface pages | On or off | On |
| Prevent organization-wide app interface sharing | On or off | On for regulated data |
| Third-party extensions | Allow all; Deny those that access non-Airtable servers (default since 26 March 2021); Deny all | Keep the default or Deny all |
| Prevent development of custom code | On with a developer allowlist | On; allowlist named developers |
Per-view share links
- Restrict access: Use Restrict access with a password or Restrict access to an email domain (paid plans), or Restrict access to enterprise email domains (Business and Enterprise Scale). Share links are not indexed by search engines, but anyone holding an unrestricted link can read the view.
- Copying and hidden fields: Turn off Allow viewers to copy data out of this view to block batch copy and CSV download (single cells can still be copied). Leave Show all fields in expanded records off, because it reveals fields hidden in the view.
- Rotation: Generate new link replaces the URL and the old link stops working. Disable link and later re-enabling keeps the same URL, so use Generate new link when a link has gone further than intended.
- Per-person access: Share links take domain restrictions rather than individual email lists. For named external people use base collaborators, interface-only collaborators or Portals.
Integrations and data movement
- Block integrations in automations and external source sync: Allowlist only the third-party services you approve.
- Block sync via emailed data and API: Turn on unless a team needs inbound sync.
- Block Google Drive shortcut integration and Slack link previews: Decide per data classification; previews show base content in chat.
- AI settings: The Airtable AI switch, the AI platforms and model developers allowlist, workspace AI access by workspace ID, AI Assistant (on by default) and Enable internet access (on by default) are all admin panel settings. Restrict AI to approved workspaces before enabling it widely.
Integrations, API tokens and service accounts
Since 1 February 2024 legacy user API keys no longer reach the Airtable API. Individual automation uses personal access tokens, and integrations that act for other users use OAuth. For the general model, see the API Keys vs OAuth Tokens Guide.
Personal access token scopes
| Scope | Grants | Use for |
|---|---|---|
| data.records:read | Read records | Reporting and export jobs |
| data.records:write | Create, edit and delete records | Intake and sync jobs that write |
| schema.bases:read / schema.bases:write | View or change tables and fields | Write only for schema tooling |
| webhook:manage | Create and delete base webhooks and fetch payloads | Event-driven integrations |
| workspacesAndBases.shares:manage | Enable, disable and delete base share links (enterprise) | Share link clean-up automation |
| enterprise.auditLogs:read | Read audit log events (enterprise admin) | SIEM collector service account |
| enterprise.scim.usersAndGroups:manage | SCIM user and group management (enterprise admin) | IdP provisioning only |
| enterprise.user:write / enterprise.account:write | Manage users and enterprise account data (enterprise admin) | Tightly held admin automation |
- Base access: Add specific bases rather than all current and future bases in a workspace. A token reads and writes only the resources assigned to it, and never more than its owner can.
- Secret handling: The token is shown once and Airtable does not store it. Tokens begin with their ID and are otherwise opaque, so detection rules should match the ID prefix pattern your scanner documents rather than a fixed length. Keep tokens in a secrets manager; see the Secrets Management Guide.
- Lifetime: Enterprise admins can set a policy capping how long PATs stay valid. Our recommendation: 90 days for people, and rotation on a schedule for service account tokens. See How to set expiry policies on personal access tokens.
- Revocation: Regenerate invalidates the old value at once while keeping name and scopes; delete removes it. Both are immediate.
- API allowlists: Block API access to organization-owned bases and workspaces limits PAT use to an allowlist (others receive INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND). Block API access for third-party integrations stops unlisted OAuth apps and stops members authorising them.
Service accounts
Enterprise Scale admins create service accounts in the admin panel Users section with a name and an email on your domain (Airtable suggests a mailing list or plus address). They cannot sign in to the UI, are not billed as users, keep working when their creator leaves and record a created by field. Admins grant workspace and base access, issue scoped PATs or authorise an OAuth integration as the service account. The default limit is 30 per plan. Service accounts owned by other organisations can appear in your Users tab tagged as service accounts; you cannot see their tokens, so restrict them with Enterprise API access control. See the NHI Discovery Guide for inventory practice.
Logging and detection
The enterprise audit log (Enterprise Scale, admins only) is in the admin panel under Reports, Audit log. Reports can be filtered by user, event category or object ID, take up to 10 minutes to generate, return at most 10,000 events per search and download as CSV. Events are searchable for 180 days. The Audit Log Events API (scope enterprise.auditLogs:read) gives near-real-time events with action, actor and time for SIEM export. Cell-level content changes are in the Change Events API, turned on with Enable Change Events by your account manager.
| Event to watch | Why | Response |
|---|---|---|
| Share link created or modified | Possible public exposure of a view or base | Check the link mode and data classification |
| Collaborator added from an unknown domain | Data access outside the organisation | Confirm with the base owner |
| Base moved or deleted | Data leaving organisation ownership or destructive change | Verify the actor and restore if needed |
| Attachment downloads in bulk | Possible exfiltration | Review the user session and token use |
| Admin panel setting or role change | Policy or privilege change | Two-person review for Admin and Integration admin changes |
Metrics that show the controls work: share links not in Members only or Private mode; PATs older than your lifetime policy; integrations on personal accounts versus service accounts; percentage of members signing in through SSO; days of audit coverage in the SIEM against the 180-day retention. See the SaaS Security Guide for cross-application monitoring.
Hardening baseline
- Discover: Use the admin panel and the Review share links view to list share links, synced views, external collaborators, extensions and service accounts.
- Identity first: Verify domains, configure SSO as optional, test with a pilot group, then set required. Turn on the enterprise two-factor requirement and set Fixed Web Session length.
- Sharing policy: Set Share links, Collaborator invites and Synced view restrictions. Choose whether existing links stay public before you change the mode, and warn owners of intake forms.
- Developer policy: Keep Third-party extensions at the default or Deny all, turn on Prevent development of custom code with an allowlist and block unlisted third-party API access.
- Tokens: Set the PAT lifetime cap, move integrations to service accounts, then turn on the PAT allowlist.
- Logging: Connect the Audit Log Events API to your SIEM with a service account holding only enterprise.auditLogs:read.
- Rollback: Each setting is a toggle in the admin panel; record the previous value before you change it so a broken workflow can be restored in minutes.
Small teams on Business plans should focus on SSO, share link restrictions on each view and per-token scopes. Large Enterprise Scale or Enterprise Hub estates add org unit admins, service accounts, IP range restrictions and SIEM export.
Common misconfigurations
- Public share links with Show all fields on: Hidden fields in the view become visible in expanded records to anyone with the link.
- Integrations on an admin's personal token: The token inherits admin data access and breaks when the admin leaves. Use a service account.
- Tokens with all bases in a workspace: New bases are added to the token automatically. Name bases explicitly.
- SSO required without a recovery path: A certificate change locks out everyone until Airtable Support resets the domain.
- Disabling instead of regenerating a leaked link: Re-enabling restores the same URL. Use Generate new link.
- Audit log left in the admin panel: After 180 days the history is gone. Export it continuously.
Framework mapping
| Airtable control | NIST SP 800-53 Rev 5 |
|---|---|
| SSO, two-factor enforcement, session length | IA-2 Identification and Authentication, AC-12 Session Termination |
| Admin roles, service accounts, PAT base access | AC-2 Account Management, AC-6 Least Privilege |
| Share links, invites, synced views | AC-3 Access Enforcement, AC-21 Information Sharing |
| Extension and custom code restrictions | CM-7 Least Functionality |
| Token lifetime and rotation | IA-5 Authenticator Management |
| Audit log export and review | AU-2 Event Logging, AU-6 Audit Record Review, SI-4 System Monitoring |
Practitioner checklist
- Verify domains, test SSO with a pilot group, then set it to required with a documented recovery path.
- Turn on the enterprise two-factor requirement for all users who access enterprise content.
- Assign User admin and Integration admin roles instead of Admin wherever possible and review stacked roles quarterly.
- Set Share links to Members only or Private and restrict Collaborator invites to your domains.
- Restrict synced views to your organisation and keep third-party extensions at the default or Deny all.
- Issue PATs with the fewest scopes and named bases, and set a maximum token lifetime.
- Run integrations on service accounts and allowlist API access to organisation bases.
- Stream audit events to the SIEM and alert on share link, collaborator and admin setting changes.
Standards and references
- Airtable: Settings, Airtable admin panel
- Airtable: Admin roles in admin panel
- Airtable: Configuring SSO in the admin panel
- Airtable: Using the view share menu
- Airtable: Personal access tokens
- Airtable: Scopes
- Airtable: Service accounts overview
- Airtable: Audit Log Events API
Related NHI Mgmt Group resources: SaaS Security Guide · SaaS and OAuth App Governance Guide · API Key Management Guide · Data Loss Prevention (DLP) Guide