Introduction
An insurance operations team builds a claims tracker in Airtable. It works, so it grows. Within a few months, it holds policy records, loss ratios, medical notes, and claimant Social Security numbers. Then a third-party broker needs to submit claims, and someone adds them as a base collaborator because that is the obvious way to grant access.
That single action exposes every table in the base. Not just the claims the broker is working on, but the full schema, every non-hidden field, the linked policy master, and the historical records of every other broker. Nothing was breached, and no attacker was involved. The permission model was simply used the way it appears to work.
This is the most common security failure in Airtable deployments, and it is entirely preventable. The fix is architectural rather than technical: separate the place where data lives from the place where people work. Everything else in this guide follows from that principle.
Why Base-Level Sharing Breaks Down in Regulated Environments
Airtable is fast because it does not force you to design a permission model before you build anything. That is an advantage during prototyping and a liability once real data arrives. Base collaboration was designed for teams working together, not for external parties who should see only one slice of a table.
Three specific problems appear once an Airtable base carries regulated data. First, view filters are a presentation feature rather than a security control, so a user with base access can change or remove them. Second, the schema itself is visible, indicating what data exists even when they cannot open it. Third, shared view links generate URLs that work for anyone who has them, and those links can be forwarded, logged in browser history, or scraped.
None of this makes Airtable unsuitable for regulated work. Airtable holds SOC 2 Type II, ISO 27001, and ISO 27701 certifications, encrypts data at rest with AES-256, and supports HIPAA workloads under a signed business associate agreement on the appropriate enterprise plan. The platform is capable. The default configuration is simply not secure.
The Permission Architecture: Interfaces Instead of Bases
The enterprise pattern is Interface-First architecture. Underwriters, external partners, and support teams interact exclusively through Airtable Interfaces. Access to the raw underlying base is restricted to admins and systems architects, and to nobody else.
The distinction matters because interfaces and bases enforce security in fundamentally different ways.
| Security Control | Base-Level Access | Interface-Level Access |
|---|---|---|
| Data visibility | Exposes all non-hidden fields and tables in the base | Restricted strictly to the elements placed on screen |
| Row-level security | Applied through view filters, which users can modify or remove | Enforced through Current User filter constraints the user cannot alter |
| Schema protection | Vulnerable to accidental alteration or deletion | Schema is fully locked. Users interact only with UI elements |
| Data export | CSV download available unless disabled organization-wide | Controlled by what the interface exposes |
| Ideal user profile | Enterprise admins and database architects | Operations teams, claims adjusters, brokers, external partners |
Read that table as a rule rather than a comparison. If a person does not need to change the structure of your data, they do not need base access.
Four Pillars of Enterprise Airtable Security
1. Enforce Row-Level Security Through Interface Filters
In multi-tenant or multi-broker environments, users must see only the records tied to their clearance or assigned queue. There is a wrong way and a right way to achieve this, and the wrong way is the one most teams reach for first.
- The anti-pattern: Creating a separate base view filtered by broker name and sending each broker a shared view link. Those links can be forwarded or intercepted, exposing underlying record identifiers to anyone who opens them.
- The best practice: Configure interface pages with a dynamic filter tied to the current user. Map the logged-in SSO email to a linked record field in your claims table, and Airtable will automatically scope the interface. The browser never fetches records outside the user’s assigned parameters, so there is nothing to intercept.
The practical difference is where enforcement happens. A shared view link filters what is displayed. A current-user filter changes what is retrieved.
2. Restrict Field and Table Editing
Row-level security controls which records a user sees. Field permissions control what they can do once they are looking at one. Sensitive fields such as loss ratios, medical notes, and identification numbers need protection from edits even by users who legitimately need to see the record.
- Set field editing permissions to “Specific users or roles only” or “Creators and above” for any field carrying regulated or financial data.
- Lock down relational junction tables such as Policy Master or Coverage Definitions, so users cannot accidentally unlink or delete foundational records that other tables depend on.
- Review field permissions whenever a new field is added. A field created after your last audit inherits default permissions, not the ones you configured for its neighbors.
3. Close the Data Exfiltration Channels
Most data leakage from Airtable happens through routes nobody classified as a risk: an unauthorized export, a public share link created for convenience, or an API token issued years ago and never revoked. These are closed at the organization level rather than on a base-by-base basis, which is the only way to make them stick.
| Admin Setting | What It Prevents |
|---|---|
| Disable public share links | Blocks external base and view sharing, which is the most common accidental exposure route |
| Restrict CSV downloads | Prevents mass data extraction by any user with view access |
| Enforce domain match capture | Automatically claims accounts created on your corporate domain, eliminating shadow accounts admins cannot see or revoke |
| Require SSO and SCIM | Centralizes authentication in Okta, Entra ID, or Ping, and automates deprovisioning when someone leaves |
| Require authentication for attachment links | Stops attachment URLs from being publicly accessible to anyone holding the link |
| Configure Enterprise Key Management | Gives your organization control of encryption keys, with documented rotation and emergency access |
One sequencing note that catches teams out: SSO must be configured before SCIM can be enabled. Plan the identity work as a single project rather than two.
4. Isolate High-Risk Workflows With One-Way Sync
When operational data has to reach third-party vendors or external adjusters, never add them to your primary working base. Use Airtable Sync to create a dedicated destination base and configure the sync source to exclude sensitive fields.
The external party then receives the minimum dataset required for their task, with no live bi-directional connection back to your primary database. If the vendor relationship ends, you delete one synced base rather than auditing which records they touched across yours.
| Case Study – UK’s Leading Insurance Company Replaces Legacy HR Performance Management Platform with Airtable |
Governing AI Agent Access to Your Data
A new category of access emerged over the past year, and most permission reviews have not kept pace with it. Airtable’s AI assistant, Omni, operates within bases and interfaces, and AI agents can now access Airtable data via the Model Context Protocol, including tools like ChatGPT and Claude.
The reassuring part is that agent access inherits the permission model you already built. Omni analyzes only the data the signed-in user is permitted to see within that specific interface, and all human and agent actions are logged and governed by the same record- and field-level permissions. If your Interface-First architecture is sound, your AI governance is largely sound with it.
What still needs deliberate attention is the admin surface. Interface-First access should be enforced for general users specifically to prevent unapproved schema changes through Omni, since a user with base-level creator rights can now restructure tables conversationally rather than manually. Organization-wide AI policy is configured centrally in Enterprise Hub, and that configuration belongs in your security review alongside SSO and DLP settings.
Get a technical audit of your Airtable security posture
Not sure whether your Airtable deployment would survive an audit? Our engineering team will review it and provide you with a prioritized list of fixes.
Book a free consultationEnterprise Governance Checklist
Before an Airtable base stores production data in a regulated environment, verify that each of these controls is in place.
| Control | What Good Looks Like |
|---|---|
| Identity management | SAML SSO enforced through Okta, Entra ID, or Ping, with MFA applied at the identity provider and SCIM handling provisioning and deprovisioning |
| Base access lockdown | Base-level editor and creator access limited to core IT and operations engineers. All general staff work through interface roles |
| Attachment protection | Authentication required for attachment links, so attachment URLs are not publicly retrievable |
| Audit logging | Enterprise audit and activity logs exported into your SIEM, covering logins, permission changes, sharing link creation, and bulk reads |
| API token hygiene | Legacy API keys fully retired in favor of scoped personal access tokens tied to service accounts with least-privilege grants |
| Data loss prevention | Public sharing and CSV export disabled organization-wide, with exceptions granted deliberately rather than by default |
| AI and agent policy | Organization-wide AI policy set in Enterprise Hub, with base-level Omni access restricted to architects |
| Workspace segmentation | Regulated data held in dedicated workspaces rather than mixed with general project work |
Legacy Airtable API keys were fully deprecated in February 2024. If any integration in your estate still authenticates with one, it is either broken or running on a token that should have been rotated years ago. Audit that first.
Scale Your Operations Without Loosening Control
A secure Airtable architecture does not require giving up the speed your operations team depends on. It requires drawing one clear boundary between raw backend data and the user-facing surfaces built on top of it, and then enforcing that boundary consistently as the deployment grows.
Teams that get this right can add departments, onboard external partners, and layer AI agents onto their workflows without reopening the security question each time. Teams that skip it end up rebuilding the permission model under audit pressure, which is considerably more expensive than designing it correctly at the start.
