How to give an AI agent safe, scoped access to data

In ADoor, each assistant, agent and app gets its own access: a space, one table, some fields or certain entries, with reading, adding, editing and deleting as separate actions. You approve requests for more, revoke at any time, and no agent gets more than the person who connected it.

An example

@ADoor Add a bug: the login button does nothing on Safari.

ADoor Cursor could only read Bugs, so it asked you for add access. You approved, and it added 1 entry

Bugs

TitleReported byCustomer
Login button does nothing on SafariCursor agentHidden from Cursor

Each connection has its own access, for example:

WhoCan reachCan do
ChatGPTPersonal workspaceRead, add, edit
Cursor agentBugs table, without the Customer fieldRead
Run tracker appRuns tableAdd
GitHub Actions jobDeploys table, for 15 minutesAdd

Give each assistant its own access

  • Choose the space when it connects. ChatGPT, Claude, Grok and Cursor sign in with OAuth, and you choose the space and approve.
  • Narrow it further. Access can name one table, and limit which fields and which entries a caller may use.
  • Agents ask for more. An agent that needs to add or edit asks through request_access, and you approve or deny.
  • Never more than you. An agent's access is capped by the person who connected it. Narrow that person's access, and the agent's shrinks too.
  • See what changed. The history shows which agent changed what, with the before and after.

Postgres enforces the access on every request. The grants and identities docs have the details.

Is MCP read only?

No. MCP itself doesn't limit what a tool can do. An MCP server decides. In ADoor, each connection's access sets it: give an agent read access only, and its writes are refused.

Revoke an agent in one step

Take an agent's access back in ADoor, and it applies from its next request. There is no shared password or connection string to rotate. What the agent wrote stays, with its name on it in the history.

How it compares with Postgres roles you set up yourself

On a database you run, on Neon or Supabase for example, you can create a read-only role, grant it one table, and give the agent its connection string. That's better when you already run the database and want full control.

ADoor fits when you'd rather not write roles for each agent: access per agent, down to specific fields or the entries that match a value you choose, approvals, and revoking from one page, with no connection string to hand out.

Questions people ask

How do you safely give an AI agent access to your data?

Give it its own connection with only the access it needs: one space or table, some fields, and read-only unless it has to write. Approve requests for more as they come, keep the history of what it changed, and revoke it in one step when you're done. In ADoor, an agent never gets more than the person who connected it.

Can I make an agent read-only?

Yes. Reading, adding, editing and deleting are separate, so an agent can have read access only.

Can an agent see just one table?

Yes. Its access can name one table, and leave out fields or entries in it.

Can two people share one connection?

No. Each person connects their own assistant and gets their own connection, with their own access and their own entries in the history.

Is it free?

A free workspace holds 1 space with 3 tables and 100 rows. Pro is $10 a month per workspace, with 1 GB of storage. See pricing.

How to start

  1. Sign in to ADoor and connect an assistant.
  2. Choose the space it can reach, then narrow it to the tables and fields it needs.
  3. Approve or deny when it asks for more.

Get your account

Updated October 20, 2026.

This page as Markdown