How an agent gets exactly your permissions

People already bring agents to work. They paste spreadsheets into chat windows because the tools holding the data have no door an agent can use, or have one that opens onto everything. Both are bad. The first is slow and scatters company data into places nobody tracks. The second quietly turns every agent into an administrator.

gtable gives every suite of apps a door, and the door knows who is walking through it.

Connecting takes an address

A suite is a set of apps that share one address and one list of people. Each suite is one MCP server, at https://<suite>.gtable.app/mcp. In Claude Code, connecting is one line:

claude mcp add --transport http acme https://acme.gtable.app/mcp

The --transport http part matters. Without it, Claude Code registers the address as a local command to run, and nothing connects. The Claude app, ChatGPT, Cursor, VS Code and Codex take the same address as a remote MCP server.

1. 1Add the addressin any MCP client
2. 2The server asks who you areand says where to sign in
3. 3You approve in your browserwhich apps, which rights
4. 4The agent works as youevery call checked against your access

Under the hood this is standard OAuth 2.1. The first request carries no credential, so the server answers that it needs one and says where to get it. The client opens your browser on your suite’s own sign-in page. You sign in, see which client is asking and where its answer will go, choose which apps it may open and what it may do, and approve. The client receives a token that acts as you.

A credential is always somebody

There is no service account in gtable, and nowhere to put one. Every key and every connection has a person behind it and is checked by the same permission compiler as that person’s screen.

When you approve a connection you can narrow it: fewer apps, fewer rights. You cannot widen it past what you have yourself.

The two sides of gtable stay apart here too. A credential made inside an app can never change that app’s structure, because designing apps is the Studio’s job, on a separate sign-in. An app’s consent screen does not even offer it.

The tools are built from what you can see

When an agent asks a suite for its tools, the answer is built for the person behind it. A table they cannot read is not in the list. The parameter that names a table only accepts the tables they can read, so an agent cannot even spell a table it has no right to. The REST API’s OpenAPI document is generated the same way, for each caller.

This matters more for agents than for people. A person who sees a greyed-out column learns that it exists. An agent told “you may not read Salary” now knows there is a Salary field, and may well mention it. So nothing is greyed out. It is absent.

Two ways to call

/mcp offers one tool per operation. That is what most clients expect, and what small models handle best.

/mcp/code offers two tools: search the API document, then execute one script that makes many calls. The script runs in a sandbox with no internet access and fixed limits on time, requests and size. A task that would have been fifty tool calls, each one a round trip, becomes one.

The agent proposes, the person applies

The assistant inside gtable works under one more rule: it does not write on its own. When it wants to change something, the change appears as a card showing what would change, and nothing is written until you approve it. A script it runs stops before its first write, for the same reason.

And whatever does the writing, a person in the grid, a script with a key or an agent over MCP, the change lands in the app’s history with who made it, and can be undone from there.

What is not there yet

gtable is not open, so none of this can be tried from outside today. The command-line tool that wraps the same API exists but is not published. When either changes, this blog will say so first.