Permission model
Who can see and change what on a pod, for people, agents, apps and API keys.
Every request to your pod is checked on the pod itself, whichever app, agent or script sends it. The pod asks two questions: who is calling, and what may that caller see and change.
Who is calling
- A person signs in to the pod (in the apps or the pod admin console) and acts as themselves.
- An agent connects with its own key and its own identity. It sees what the person it works for can see, and its changes are recorded as the agent's.
- An app that you approve gets its own agent identity too, so its changes follow the same rules as an agent's.
- A script or integration uses an API key that acts for the person who created it.
What a person can see
Records live in spaces (workspaces). Each kind is either shared by the whole pod, like person and company, or kept
inside the space it belongs to, like a CRM deal. You see a space's records when you are a member of that space.
Each member of a space has a role:
| Role | What it adds |
|---|---|
| Viewer | Reads the space's records and views |
| Editor | Also creates, edits and archives records |
| Admin | Also manages the space and invites members |
| Owner | Also deletes |
When your role does not allow a change, you can still ask for it: the change becomes a proposal (shown in the apps as a Request) for the space's owners and admins to approve. A space can let its editors approve too. If nobody else could approve it, the change is refused.
What a key can do
An API key has two limits on top of the person it acts for:
- its scopes name the API surfaces it may call, such as the Hub REST API or MCP;
- its grant narrows what it may touch there: some kinds, some actions, some spaces, projects or single records.
A key can never do more than its person can. See API keys.
What happens to a change
A person's change runs when that person's role allows it. A change made by an agent, an app or an automation passes the same check, then goes through the validation policy: it runs directly, becomes a proposal for a person to approve, or is refused.
Because the checks run on the pod and not in the apps, the same rules hold for the apps, MCP, the Hub REST API and the SDK.
See also: