--- title: "An app is a database plus permissions." description: "Set the data and who may see what, once. Then people use the app any way they like, from the grid to their own AI agent, always inside their permissions." language: en canonical: https://grid82.com/ source: Grid82 website --- # An app is a database plus permissions. Your users then use it the way they like: the grid, pages, the API or their AI agent, with permissions always enforced. [Read why](https://grid82.com/blog/database-plus-permissions) ยท [How agents connect](https://grid82.com/agents) ## Three surfaces, one definition The builder sets the rules once. Each person then works the way they like, always on their own slice. - **Work in the same grid.** The real tables, with views, filters, grouping and linked records. Everyone opens the same grid and finds only their own rows in it. - **Describe the screen you need.** Ask the assistant for a dashboard, a board or a form, and it builds the page on your data. Every page reads through the permissions of whoever opens it. - **Connect your agent.** Every suite is an MCP server and every app has a REST API. Connect Claude, ChatGPT or Cursor and it works as you, with exactly your access. ## Two products, one definition Builders design apps in the Studio: tables, roles, rules and people. Everyone else signs in to the app at your suite's address. Switch the Studio off and every app keeps running. ### Studio For builders Where apps are designed: tables and fields, user roles and what each may see, the people invited, the suite's address. It has its own assistant and its own MCP server, so an agent can build an app with you. ### App For the people you invite They sign in at their suite's address and land in the app: Data, Interface and their own settings, with an assistant that works inside exactly their access. The test of the split: switch the Studio off and every app keeps working. An app's definition lives beside its data, so serving a request never asks the Studio anything. ## Permissions that hold everywhere One compiler decides what each person may read and do, in the grid, the API, MCP and the assistant. Roles only add access, and every app has its own database. - **Which tables.** A table a person may not read is not on their screen, not in their API document and not among their agent's tools. - **Which rows.** "Only the deals I own" is a rule the database applies to every read, not a filter somebody can take off. - **Which fields.** A field you cannot read is never returned and never named, not even in an error message. - **Which actions.** Creating, editing and deleting are granted per table, each with its own say on which records. Seeing and editing are set field by field. - **Roles only add.** A person's access is the union of their user roles. Adding a role can only add access. No role is special and there is no admin mode inside an app. - **One database per app.** Each app has its own SQLite database. One app's rows never share a database with another's. ## Your agent gets exactly your permissions A credential always acts as a person. An agent connected with your account has your permissions. It can have fewer, never more. ```sh claude mcp add --transport http acme https://acme.grid82.app/mcp ``` The first call opens your browser. You sign in, choose which apps it may open and what it may do, and the agent is connected as you. [More on agents](https://grid82.com/agents). Your agent reaches your app through the same permission compiler. ## The agent proposes, you apply The assistant inside Grid82 does not write on its own. A change arrives as a card showing what would change, and nothing happens until you approve it. Every write, by a person, a script or an agent, is recorded in a history it can be undone from. ## Build around the way your team works. A CRM, a client portal or a project workspace starts with connected records and clear rules. - [CRM](https://grid82.com/apps/crm): Build a connected customer model with companies, contacts and deals, then choose who can read and edit each part of it. - [Project management](https://grid82.com/apps/project-management): Build a project app with related tasks and clients, so every view draws from the same work and respects the same access rules. - [Client portals](https://grid82.com/apps/client-portals): Design a client portal on your actual project data, with row and field rules that define exactly what each invited client may see. [Explore all solutions](https://grid82.com/solutions) ## Questions ### How do I get access? Join the [waitlist](https://grid82.com/#waitlist). Access opens from it, and your invitation comes by email. ### What is the difference between the Studio and an app? The Studio is where a builder designs apps: tables, user roles, rules and people. An app is what invited people use, at their suite's address. They have separate sign-ins, and an app keeps working without the Studio. ### What is a suite? A set of apps that share one address, one login page and one list of people. The same person in two suites has two separate accounts, on purpose. ### Which agents can connect? Any MCP client that supports remote servers with OAuth, including Claude Code, the Claude app, ChatGPT, Cursor, VS Code and Codex. A script can use the REST API with a key instead. ### Can an agent see more than I can? No. A key or an OAuth connection acts as the person who made it, and the same permission compiler checks it as checks their screen. It can be narrower than you, never wider. ### Where does the data live? Each app has its own SQLite database, running on Cloudflare's network. Two apps never share one. ## Get access to Grid82 Access opens from the waitlist. Leave your email and your invitation comes by email. [Read the blog](https://grid82.com/blog)