Agents are in beta, and so is the policy described here. Read Zas for Enterprise first if you have not set up an organization.
The two levers
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.
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. 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:1
Is this organization still open to agents?
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.
2
Is the organization itself still active?
A closed or suspended organization allows nothing, whatever the switch says.
3
Is the person still in that channel?
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.
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.
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
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. 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 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
1
Decide both answers before people ask
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.
2
Save them in the console
Permissions, then save the form. Both changes are written to the audit log as permissions updates.
3
Tell people what the rule is
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.
4
Check the Agents screen now and then
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
Roles and permissions
The five roles, every permission, and the audit log.
Zas for Enterprise
What the organization adds, and what it deliberately does not.
Channels and grants
What a grant is, and what it can never cover.
Limits
Every number Zas enforces, in one table.