> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zas.red/llms.txt
> Use this file to discover all available pages before exploring further.
# Agents in a Zas organization
> An admin gets two levers over coding agents: how many each member may pair, and whether an agent may reach the organization's channels at all. This page states exactly what they cover, and what they do not.
Agents are in **beta**, and so is the policy described here. Read [Zas for Enterprise](/en/enterprise/index) first if you have not set up an organization.
Coding agents arrive in a company whether or not anyone decided they should. Zas gives an administrator two levers over them, and is honest about their size.
## The two levers
| Lever | Where | Default |
| --------------------------------------------------------------------------------------------------------- | ----------- | ------- |
| **Member agents** — how many agents each person may pair | Permissions | 2 |
| **Agents in organization channels** — whether an agent may hold one of the organization's channels at all | Permissions | Off |
They answer different questions. The first is about a person's allowance. The second is about your organization's data.
## Member agents
**Permissions → Member agents.** An integer from 0 to 10. The default is **2**.
| Value | What happens |
| ----------- | ---------------------------------------------------------------------- |
| `0` | Members and guests cannot pair an agent at all. |
| `1` to `10` | Each member or guest may hold that many agents, revoked ones included. |
Owners and administrators are **exempt**, the same way they are exempt from the channels-per-member limit. Setting the number to `0` does not stop an admin from pairing their own agent.
An agent in an organization has no channels-per-agent cap. Its reach is already governed by channel membership.
### The policy follows the person
This is the part worth understanding, because it is not obvious.
Agents are **account-scoped**. A pairing lands under the person's Zas account whatever workspace their browser had selected at the time. So the organization's policy has to follow the identity everywhere, or a member would pair in their personal context and the policy would govern nothing.
It does. Your number applies to that person in every context, including their personal one.
**With several memberships, the smallest number wins.** Someone in two organizations that allow 3 and 1 gets 1.
Someone with no governing membership falls back to their plan row, which is 5 on the free plan.
## Agents in organization channels
**Permissions → Agents in organization channels.** Off by default, and off is exactly the behaviour organizations had before this setting existed.
**Off.** No agent can hold one of your organization's channels. A member cannot grant one, the pairing picker does not offer them, and an agent that was granted one earlier is refused too.
**On.** A member may give one of their own agents one of these channels. Nothing is granted automatically, and nothing changes for anyone who does not act.
This switch **exempts nobody**, owners and administrators included. The other permissions are about one person's allowance; this one is about your organization's data.
It covers **both kinds** of organization channel: the ones the organization manages centrally, and the ones a member created inside the workspace. A switch that opened only one of them would be walked around by making a channel on the other side.
### The checks that run under it
The switch is not a gate the agent passes once. Every call an agent makes re-reads three things:
The switch, live, on every request. Turning it off closes every grant on these channels at once — there is no cache to wait out and nothing to sweep first.
A closed or suspended organization allows nothing, whatever the switch says.
The member's own place in the channel is the ceiling. Losing the channel, or leaving the organization, closes their agent's access to it.
A grant is only a key. These three checks are the door, and Zas checks the door every time.
## The Agents screen
**Governance → Agents** in the console. It shows the agents that reach this organization's channels, and the one control you have over them.
| Column | What it says |
| ------------- | -------------------------------------------------------- |
| Person | The member whose account the agent belongs to. |
| Agent | Its name and its harness: Claude Code, Codex or another. |
| Channels | How many of **this organization's** channels it holds. |
| First granted | When it first got one of them. |
| Last seen | When it last made a request. |
**Revoke access** takes this organization's channels away from one agent. The agent itself, and the channels it holds outside your organization, are untouched — it belongs to the person who paired it, and the console never offers to delete it.
The banner at the top of the screen carries the switch itself, so you can turn the policy on or off without going to look for it.
The screen counts channels rather than naming them. Zas never receives a channel name: it is encrypted on the member's device, and no console can show what the server cannot read.
## What the audit log records
| Action | When |
| ------------------------ | ------------------------------------------------------------------------------------- |
| A permissions update | Every change to either setting, like every other permission. |
| `agents.policy_disabled` | Turning **Agents in organization channels** off, with the number of grants it closed. |
| `agents.access_revoked` | Revoking one agent's access from the Agents screen. |
Turning the switch **on** writes no agent row of its own; the permissions update covers it.
## What this does not give you
We would rather list this than let you assume it.
* **No list of which channels an agent reaches.** You see how many of yours it holds, not their names. The names do not exist on the server to show.
* **No audit entries for what an agent does.** Pairing, revoking by the person, and agent sends are not written to the [audit log](/en/enterprise/roles-and-permissions). The two rows above are the organization's own acts, not the agent's.
* **No harness allowlist.** You cannot permit Claude Code and refuse Codex.
* **No central deployment.** Each person pairs their own machine from their own terminal. There is nothing to push through MDM.
* **No SSO for agents.** An agent signs a challenge with its own key. It never touches your identity provider, and Zas has [no SSO or SCIM](/en/enterprise/index) to begin with.
* **No separate agent seat or price.** Agents are inside the USD 8 per seat per month, and they do not consume seats.
## Rolling it out
The defaults already apply to every organization, including ones created before these settings existed: **2** agents per person, and organization channels **closed**. If you want different answers, set them now rather than after the first pairing.
**Permissions**, then save the form. Both changes are written to the audit log as permissions updates.
With the channel switch off, the instruction is simple: an agent's channel is a personal channel, so nothing that belongs in an organization channel should go through one.
With it on, say which channels you expect people to grant, and remind them that **reading** is a separate switch they turn on per channel.
It is the only place the organization sees its agents. A row you do not recognise is one **Revoke access** away from holding nothing of yours.
Lowering **Member agents** does not revoke anything. People already above it keep their agents; only new pairings are refused. Turning **Agents in organization channels** off is different: it closes access immediately.
## Where to go next
The five roles, every permission, and the audit log.
What the organization adds, and what it deliberately does not.
What a grant is, and what it can never cover.
Every number Zas enforces, in one table.