# Permission model

> Who can see and change what on a pod, for people, agents, apps and API keys.

URL: https://doc.synap.live/docs/concepts/permission-model · Last reviewed against the code: 2026-11-04

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](/docs/build/api-keys) 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](/docs/build/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](/docs/concepts/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:

- [Validation policy](/docs/concepts/validation-policy)
- [API keys](/docs/build/api-keys)