# Validation policy

> How the pod decides whether a requested change runs directly, becomes a proposal, or is refused.

URL: https://doc.synap.live/docs/concepts/validation-policy · Last reviewed against the code: 2026-11-03

The validation policy decides what happens to a change an agent asks to make: it runs directly, it becomes a proposal
(shown in the apps as a **Request**) that waits for a person, or it is refused.

## People and agents

A change made by a person runs if that person has the permission for it. See
[Permission model](/docs/concepts/permission-model).

A change made by an agent goes through the same permission check first, then through the policy below.

## Write modes

Each agent has a write mode. You choose it when you connect the agent: the page in the pod admin console where you
approve a computer and its agents (`synap init`) asks how the agents' changes land, and `synap connect claude-code`
asks the same in the terminal. You can change it at any time on the agent's page in the pod admin console.

| Write mode | What it does |
|---|---|
| **Normal** (recommended, the default) | Creates and edits apply directly with Undo; deletions and structural changes ask you. |
| **Creates only** | Creates apply directly with Undo; edits, deletions and structural changes ask you. |
| **Ask first** | Every change asks you first. |

An agent you have not configured follows the pod's default, which is **Normal**: a pod-wide rule lets an agent's
reversible writes run directly. A change that runs directly is still recorded, and you can undo it.

## What always asks you

Some changes become a proposal whatever the write mode and whatever rule you add. No rule can widen them:

- **Destructive actions**: delete, archive, purge and merge.
- **Administrative actions**: changing a space's settings, adding or removing members, changing a member's role,
  changing what an agent may do.
- **Changes of scope or identity**, for example making a record visible to the whole pod, or changing its kind.
- **An agent defining a kind or a role.** A person defining one is not affected.
- **An agent creating a space, cell, playbook or automation**, or activating an automation. A person doing the same
  is not affected.
- **Human gates**: approvals whose whole purpose is that a person says yes, such as approving a plan before an agent
  writes code.

An agent's own key can never approve a proposal, its own or anyone else's. Approval is a human step.

## Other things that make a change ask you

- **Rules you add.** On top of the write mode, you can add rules that let a kind of write run directly or make it ask
  you, for one agent or for the whole pod. A rule can never loosen the list above.
- **Untrusted origin.** A write that comes from outside the pod's trusted channels, such as an external connector,
  becomes a proposal even when the agent's write mode would run it directly.
- **A daily limit.** A pod can cap how many writes an agent runs directly each day; past the cap, the rest become
  proposals. There is no cap unless one is set.

## Refused

A change is refused when the caller lacks the permission for it, when the agent lacks the capability it needs, or when
a person set a rule that says never.

## What an app or script sees

A write through MCP, the SDK or the Hub REST API answers with the outcome. A proposal comes back as
`status: "proposed"` with a `proposalId`; this is a success, not an error. The change is applied when a person
approves the proposal.

See also:

- [Permission model](/docs/concepts/permission-model)
- [Connect your AI](/docs/agents)