> ## 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.
# Grants: which channels an agent may use
> A grant is one channel an agent may use, with two switches for sending and reading. Change it or revoke it at any time from Settings, and the agent feels it on its next request.
Agents are in **beta**. What this page describes is what the server enforces today.
An agent reaches a channel only through a **grant**. No grant, no key, no access.
## What a grant is
A grant is one channel, plus two switches, plus that channel's key sealed to the agent's public key.
| Switch | What it allows |
| -------- | -------------------------------------------------------------------------- |
| **Send** | `zas_send_file`, `zas_send_note` and `zas_send_direct` into that channel. |
| **Read** | `zas_list_items`, `zas_get_item` and `zas_receive_direct` in that channel. |
Sending is the default when you approve a pairing. Reading is a separate switch, and it stays off until you turn it on.
`zas_edit_item` and `zas_replace_file` take both switches: they read the item first, then write over it.
The two are independent. An agent that only sends is the common case: it drops a build or a screenshot into a channel and never looks at what else is there.
Receiving a Directo transfer takes the **read** switch, not the send switch. It writes a file onto the machine the agent runs on, which is a read of the channel, whichever direction the bytes travel.
## Where you change them
**Settings → Agents.** Each agent shows its name, its harness, its host and its last send, then one row per channel with the two switches and a link to remove it. **Add a channel** opens the same picker the pairing page uses.
Every channel that has an agent also carries a strip above its items, listing each agent and its switches. You can remove an agent from a channel right there.
A change takes effect on the agent's **next request**. The server reads the live grant every time, so there is no cache to wait out.
## Revoking
**Settings → Agents → the agent → Revoke.**
The session stops, the refresh tokens are revoked, and the agent's next tool call answers `The owner revoked this agent`.
What it already sent stays where it is. Agent items are your items: they expire on the normal clock, and you delete them the way you delete anything else.
To narrow instead of revoke, drop a single channel and keep the rest.
## The numbers
| | Without an account | Free plan |
| ------------------ | ------------------ | --------- |
| Agents | None | 5 |
| Channels per agent | — | 5 |
In an organization, an admin sets the number of agents per person, and there is no channels-per-agent cap. See [Agents in an organization](/en/agents/enterprise).
Two rules surprise people, so they are worth stating plainly.
**A revoked agent keeps its slot.** The count includes revoked agents. Delete one to free the slot.
**Removing a channel does not free a channel slot.** The reach counts every channel the agent was ever granted, not the ones it holds now. An agent that has used its five channels needs to be deleted and paired again to point at different ones.
## Organization channels
A channel an organization manages is grantable only when that organization has turned agents on. The switch is **Permissions → Agents in organization channels**, it is off by default, and an administrator owns it.
Two things follow from where the check runs:
* **The switch is read on every call, not at grant time.** Turning it off closes every grant on those channels immediately. A grant is only a key; the door is checked each time.
* **Your own place in the channel is the ceiling.** Leaving the channel, or leaving the organization, closes your agent's access to it whatever the switch says.
While the switch is off, an organization's channels are out of reach of every agent, and the picker does not offer them.
## What a grant can never cover
* **A channel you only joined.** Grants exist on channels your own account owns, and on organization-managed channels the organization has opened.
* **Your [Private channel](/en/using-zas/channels)** is grantable like any channel you own, but think before you do it. It is the one place nothing is shared.
* **A view-only channel.**
## What the server checks anyway
The switches in the interface are not the only line. Behind them:
* The API answers an agent on a **fixed allowlist of routes** and refuses every other one. Adding a route to Zas never widens what an agent can do by accident.
* Database rules refuse an agent your account document, your devices, and any channel with no active read grant.
* Rate limits run on their own buckets, and key derivation is charged to your account, so ten agents are not ten times your own allowance.
* The server never sees a channel key, a channel name or item content. That does not change because an agent is the one sending. See [Encryption](/en/concepts/encryption).
## Where to go next
Which channel to grant, and what never to send.
The two levers an admin has, and what they show.
Private and shared channels, and the per-plan limits.
The full list, written plainly.