# Controls

Sometimes you want more control over what an agent or AI tool can do within Airtable or specific apps within it. Both users and enterprise admins have several ways to control the data that agents and third-party AI systems can access.

## User controls

### Scoping access: which bases an agent can see

Every connection to the Airtable MCP server is scoped — agents can only access what you explicitly authorize.

**With OAuth**, you choose your scope during the authorization flow:

-   **Everything you have access to** — all current and future bases and interfaces across your workspaces
-   **Custom access** — specific bases, interfaces, or workspaces you select

Update these settings any time from your [third-party integration settings](https://airtable.com/?integrations=thirdParty) without re-authorizing from scratch. You can also disconnect and reconnect via the client's UI to update permissions.

**With PATs**, granular scopes are set at token creation time by selecting specific scopes (the actions an agent can perform) and specific resources (which bases, apps, or workspaces it can operate within). Change a token's configuration any time at [airtable.com/create/tokens](https://airtable.com/create/tokens). If different agents need different data, create a separate PAT scoped to each subset and configure each MCP connection with the appropriate token.

### Read-only vs. read-write access

The MCP server respects your existing Airtable permissions. If a user has read-only access to a base, they cannot write to it via MCP — the server enforces the same permission boundaries as the Airtable UI and REST API.

For tighter control, you can make an agent's access read-only by omitting `data.records:write` and `schema.bases:write` when setting up your PAT or OAuth consent. This is useful for analytics or reporting workflows where write access isn't needed and you want to prevent accidental modifications.

### Understanding what actions agents have taken

When an agent writes data to a record, you can always review the revision history for that record. Revision history shows who made the change (the user who authorized the MCP connection) and what entity performed it (the name of the OAuth app or the PAT the user configured when connecting to Airtable via MCP).

**What happens if I try to update a field I don't have permission to modify?**

The MCP server returns an error, just as the Airtable API would. Your AI assistant should communicate this limitation to you.

## Organizational controls

For customers on Enterprise Scale plans, admins have several ways to control usage of MCP.

**Block MCP access.** Admins can block MCP access outright. From the [Admin Panel](https://airtable.com/admin) → Integrations & development → Development settings, admins can enable "Block MCP access." This prevents third-party MCP clients, like ChatGPT and Claude, from accessing bases and workspaces owned by that organization, whether the client connects with OAuth or a PAT. Organization-owned bases and workspaces also stop appearing when a blocked client lists available resources. Airtable's built-in AI features and traffic going directly to Airtable's REST APIs are unaffected and can be controlled separately. On Enterprise Hub, the setting is configurable per org unit, and hub admins can lock it.

**Block all third-party API integrations.** From the [Admin Panel](https://airtable.com/admin) → Integrations & development → Development settings, admins can enable "Block API access for third-party integrations." This prevents any OAuth-connected application, including MCP clients, from accessing bases owned by that organization — even when "Block MCP access" is off.

**Allowlist specific connectors.** If third-party integrations are blocked but you want to permit specific MCP clients, an admin can add their OAuth client IDs to the allowlist in the Admin Panel:

| Client                   | OAuth Client ID                                       |
| ------------------------ | ----------------------------------------------------- |
| Claude Code              | `https://claude.ai/oauth/claude-code-client-metadata` |
| Claude.ai                | `266cb1c0-b4ae-43a1-b7d7-c2a563667d95`                |
| ChatGPT                  | `7a713e1a-3d99-4fdf-b59a-311bdf94ba97`                |
| Amazon Quick             | `7841dde5-28ec-4ea0-972a-509425dbe5fa`                |
| Google Gemini            | `c42492f3-1e79-450d-bf82-9a32316fe763`                |
| Google Gemini Enterprise | `8e053d1c-91b5-457b-a1e9-09478808159e`                |

Allowlisting a client ID lets a user connect to bases in their organization _only_ from OAuth apps that have been approved by an enterprise admin. Note that "Block MCP access" takes precedence: while it's enabled, MCP clients are blocked even if their client ID is on the allowlist.

## Data privacy FAQs

### Data privacy and retention

The Airtable MCP server sees only the structured arguments of each tool call — not the prompt or conversation that triggered it. For example, if a user asks their AI tool to update a record, Airtable receives the target table ID, record ID, and field values, but not the original natural language request.

Data retention for MCP activity follows the same policies as the Airtable REST API. Airtable does not store prompt context or conversation history from your AI tool. Many AI clients (including Claude) display the specific arguments being sent to Airtable, so users can inspect exactly what data is being passed.