An Airtable personal access token lets whoever holds it call the Airtable API with the scopes and the bases that were chosen when it was created. Depending on those choices, that can mean reading every record of a base, changing or deleting them, editing the structure of a table, or creating webhooks that send your data elsewhere. Airtable bases often hold customer lists, orders, applicant data or inventory, so a leaked token can be a data exposure and not only a nuisance. Revoke it first, then work out what it could reach.
Check your GitHub account for leaked secrets — free
- Provider
- Airtable
- Severity
- Critical
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- No
What an Airtable personal access token looks like
A token starts with pat, then 14 letters and digits, a dot, and 64 hexadecimal characters:
pat…XXXX.…XXXX Airtable personal access token (masked: 14-character ID, dot, 64 hex characters)
The first part before the dot identifies the token and the second part is the secret. Older Airtable API keys, which began with key, were deprecated in favour of these tokens, so an old script may still use the previous format. If your leaked credential starts with key, treat it as a legacy API key and follow the same steps: it would have the access of its owner across all of that user’s bases. The variable holding a token is usually AIRTABLE_PAT, AIRTABLE_API_KEY or AIRTABLE_TOKEN.
How Airtable personal access tokens get leaked
- Hardcoded in an automation script. A sync or import job that talks to Airtable with the token typed into the code.
- Committed environment files.
AIRTABLE_PATin a.envfile kept in the repository. - Front-end code. A site or app that reads a base straight from the browser, using the token as if it were a public key.
- No-code exports and shared configs. A workflow export, a form handler or an integration config posted for help.
- Documentation and tutorials. A curl example with a real
Authorization: Bearerheader left in a README or issue.
What to do in the first hour
- Open your tokens page in Airtable (see the link below) and find the exposed token by its name. The page lists the token’s scopes and the bases it is allowed to reach, which tells you immediately how bad the leak is.
- Revoke the token by deleting it, or regenerate it if the page offers that option and you still need a token of that name. Do this before cleaning anything else.
- Create a replacement with the smallest set of scopes and the fewest bases that the service needs. Avoid granting write or schema scopes to a job that only reads.
- Deploy the new token to the application or secret store, and confirm that the job still works.
- Audit the bases it reached. Use the revision history of the affected records and tables to look for changes, deletions or imports you did not make. Check whether any new fields, tables or views appeared.
- Check webhooks and integrations. If the token had the scope to manage webhooks, list the webhooks on each reachable base and remove any you do not recognize. A webhook that forwards your changes to a stranger keeps working even after the token is gone.
- Look at what else leaked in the same file. See I accidentally pushed an API key to GitHub.
Not sure what else leaked from the same repository? Run a free scan.
Revoke it at Airtable
Airtable personal access tokens are managed from the tokens page of your Airtable account, after you sign in as the user who created them. Open the exposed token and delete it. Tokens belong to the user who created them, so if the creator has left the company, an administrator may need to review their access. A person has not confirmed the exact menu wording for this guide, and the interface can change, so if what you see differs, look for the developer hub section where tokens are listed, and follow Airtable’s documentation.
How LeakWatch detects it
The rule is called Airtable Personal Access Token. It recognizes pat, 14 letters and digits, a dot and 64 hexadecimal characters, with word boundaries on each side, and accepts hexadecimal in either case. A shorter identifier, a character outside the hexadecimal alphabet or a dash instead of the dot is not reported. A separate, older rule covers the same format in lowercase only, so a lowercase token can appear under both names. The severity is critical, because the token can open the contents of whole bases. This type is not checked live: LeakWatch does not send any request to Airtable with the token it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Does the token give access to my whole Airtable account?
No. A personal access token only reaches the bases and scopes chosen at creation. Check the token’s entry in your tokens page to see exactly what it covered.
Can I see whether someone read my data?
Reads usually leave no trace in the base itself, so you cannot prove that nothing was read. Revision history shows changes, not reads. Treat the data as exposed if the token was public and could read it.
What if the token was shared by a former colleague's account?
Tokens belong to the account that created them. Ask an administrator to review that account’s tokens and, where needed, create new ones under a service account.