Most Airtable security incidents we get called about are not breaches. They are a share link that was pasted into a public doc two years ago, an ex-contractor who still has creator access, or a base where "everyone in the company" can delete records. Airtable gives you the controls; almost nobody audits them. This checklist is the one we run at the start of every engagement. Work through it top to bottom on your most important base and you will find something.
1. Understand the three permission layers
Permissions in Airtable stack:
- Workspace permissions apply to every base in the workspace. A workspace owner can do anything to any base in it, including delete it and change billing.
- Base permissions (Owner/Creator, Editor, Commenter, Read-only) apply to one base and are what most people think of as "access".
- Interface permissions apply to one interface and can be granted to people who have no base access at all.
The practical consequence: someone who is a workspace owner for convenience has full control over bases they have never opened. Audit the workspace layer first.
Check: open the workspace's collaborators list. Every owner should be able to justify it. Move everyone else to workspace member or, better, give them access at the base level only.
2. Base collaborators: right role, right people
Open each base's share dialog and review the list.
- Creator can change schema, automations, and sharing. Limit to the people who actually build.
- Editor can change data in every table, including deleting records. That is more than most roles need.
- Commenter and Read-only are underused. If a person's job is to look and occasionally flag, they do not need Editor.
Check: anyone marked Creator who is not on the build team; anyone who has left the company or whose contract ended; any shared mailbox or generic account with access.
Fix: downgrade or remove. For people who need to edit a few fields, build an interface with per-field editability instead of granting Editor on the base (see our Interface Designer guide).
3. Share links: the quiet leak
Every view, form, and base can have a public share link. Once created, it works for anyone who has it, indefinitely, unless you disable it or restrict it.
Check: for each base, open the share settings and list every active view share, form share, and base share link. For each one ask: do we know who has this URL?
Fix:
- Disable links nobody can account for.
- For links that must stay, enable a password and, where the plan supports it, restrict to a specific email domain.
- Turn off "allow viewers to copy data out of this view" on read-only view shares unless export is the point.
- Re-create links that were widely distributed; the old URL stops working and you distribute the new one deliberately.
Put a recurring quarterly reminder in the calendar to redo this step. Share links multiply.
4. Interface sharing
Interfaces can be shared with individuals, with everyone in the workspace, or publicly (depending on plan and settings).
Check: any interface shared more broadly than its audience. A "Leadership dashboard" shared with the whole workspace is a common one.
Fix: share with the specific people or group. Review per-page editability and whether record creation or deletion is enabled on pages where it should not be.
5. Field-level exposure
Airtable does not have field-level permissions on the base itself; anyone who can see a table sees all its fields. Hidden fields in a view are hidden, not protected.
Check: fields containing salaries, personal data, credentials, or contract values in tables that broad groups can open.
Fix: move sensitive fields into a separate table with tighter access, linked to the main table, and expose them only through interfaces restricted to the right audience. If you ever stored an API key or password in a field, rotate it now; it is in the revision history forever.
6. API tokens and integrations
Since February 2024 all API access uses scoped personal access tokens or OAuth, which is a large improvement over the old all-powerful API keys, but only if the tokens are scoped.
Check: in each builder's account, list personal access tokens. For each: what is it for, which scopes, which bases, when was it last used?
Fix: delete tokens nobody can explain. Re-issue tokens that have access to "all workspaces" with access to specific bases only. Tokens belong to people; when a person leaves, their tokens stop working, so put unattended integrations on a dedicated service account rather than a departing employee's login. Our API quickstart covers scopes in detail.
Also review third-party apps connected via OAuth (under account settings). Revoke anything you no longer use.
7. Automations and scripts
Automations run with the permissions of the user who created them and can send data anywhere: Slack, email, webhooks to arbitrary URLs.
Check: every automation with a "Send webhook" or "Run script" step that calls an external URL. Where does the data go, and is that URL still yours?
Fix: document each outbound integration in a table in the base (name, destination, owner, data sent). Reassign automations created by departed users; they will stop running when that account is removed.
8. AI features and what leaves the base
AI field agents and AI automation steps send the fields you put into the prompt to a model. If those fields contain regulated data, that is a data-processing decision, not just a product feature.
Check: every AI field's prompt, and which fields are inserted into it.
Fix: remove fields that do not affect the decision; confirm with whoever owns your privacy policy that AI processing of that data is covered. See our Airtable AI consulting page for how we approach governance.
9. Revision history, backups, and recovery
Airtable keeps record revision history and base snapshots, with retention depending on plan. Deleted records sit in a trash for a limited period. That is recovery, not backup.
Check: do you have an export of your important bases that is not inside Airtable? Could you restore last Tuesday's state if someone ran a bad batch update?
Fix: schedule a regular export (CSV per table via the API, or a scheduled sync to a warehouse) and actually test a restore once. For bases that matter, take a manual snapshot before any schema change or bulk import.
10. Enterprise controls, if you have them
Enterprise plans add an admin panel with user management, SSO and SCIM provisioning, domain-restricted sharing, audit logs, and the ability to see every base and share link across the organisation. If you are on an Enterprise plan and have not opened the admin panel's share-link report, do it today; it does the whole of step 3 for you across every workspace.
Check: SSO enforced; deprovisioning connected to your identity provider; domain restrictions on sharing enabled; audit log retained and someone reviewing it.
11. Data hygiene as a security control
Messy data creates security problems: duplicate People records mean one gets deprovisioned and the other does not; a free-text "Owner" field means current-user interface filters cannot work, so teams fall back to sharing the whole base.
Check: collaborator fields used for ownership rather than text; one record per person; stale records archived into a separate table rather than left in the working set.
The checklist in one place
- Workspace owners justified.
- Base roles minimal; ex-staff removed.
- Every share link accounted for; passwords or domain restriction on the survivors.
- Interfaces shared with their audience only.
- Sensitive fields isolated into restricted tables.
- API tokens scoped and owned by service accounts.
- Outbound automations documented.
- AI prompts reviewed for data exposure.
- Off-platform backup exists and has been restored once.
- Enterprise admin controls switched on.
- Ownership fields are collaborator fields; no duplicate people.
BaseBrainers runs this audit as a fixed-scope engagement under Airtable Security and Compliance. If you would rather not run it yourself, contact us.