---
title: Agents and access
description: Open an agent in Settings to see its tabs, add users, grant what each person may do and replace an old Everyone signed in grant.
canonical_url: https://hubzoid.com/docs/settings/agents-and-access
last_updated: 2026-10-25
---

# Agents and access

Open an agent in Settings to see its tabs, add users, grant what each person may do and replace an old Everyone signed in grant.

Each hub in a deployment appears in Settings as an agent. An agent's page is where you decide who can use it and what each person may do, and where you read its instructions, connectors, workflows, evals and configuration.

By the end of this page you can add a teammate, give them the right capabilities and check what an agent's other tabs show. The rules behind every grant are in [Identity and access](https://hubzoid.com/docs/concepts/identity-and-access).

![The My Hub agent page in Settings on its Access tab, People part. Tabs Instructions, Access, Connectors, Workflows, Evals, Feedback and Configuration. Lee Okafor and Priya Raman have Use this agent, Sam Rivera has Use this agent and Manage access inherited, all Active, each with Edit access. Add user is at the top right.](https://hubzoid.com/docs-assets/app/team-agent-access-light.webp)

The Access tab lists who can use the agent and what each person may do.

## The agent list

**Settings** → **Agents** lists one row for every agent you manage. Search with **Find an agent** by name or key, and narrow the list with **All**, **Needs attention** or **Not used yet**. Select a row to open the agent on its **Access** tab. **Chat** on a row opens a chat with the agent when you can use it yourself.

**Every column in the agent list**

| Column | Contents |
| --- | --- |
| Agent | The agent's name and its key, the hub folder name in lowercase |
| In its folder | What the folder holds, such as knowledge, skills, workflows and connectors, or **Only instructions** |
| People | How many people have access, or **Everyone** for an agent open to everyone signed in |
| Chats, 30 days | Chats with the agent in the last 30 days |
| Spend, 30 days | The approximate cost of the last 30 days |
| Last used | When the agent was last used, or **Not yet** |
| Status | **Ready**, **Workflow failing** when a workflow could not be loaded or the scheduler stopped, or **Evals N of M** when the latest eval run passed only N of M cases |

## An agent's tabs

The agent page shows its name and description, **View activity** (the audit log for this agent) and **Open chat**. Below are its tabs. Each tab has its own address, `/settings#/agents/<key>/<tab>`.

| Tab | What it shows | With browser editing off |
| --- | --- | --- |
| **Instructions** | The agent's `AGENTS.md`, skills and shared prompts, with each file's Git history | Read-only. With it on, the tab has **Files** and **Changes to review** (Beta) |
| **Access** | **People**: who can use the agent and with which capabilities. **Workflow permissions**: who may run, schedule, change and see each workflow | Editable |
| **Connectors** | The apps the agent can use for people, and the servers in its `connectors/.mcp.json` | Read-only |
| **Workflows** | Its markdown tasks and code workflows, their status, who they run as, and their runs. See [Runs](https://hubzoid.com/docs/settings/runs) | **Run now** works |
| **Work** | **Work items**, **Incoming messages** and **Sandboxes**. Shown only when the agent has any of them |  |
| **Evals** | Its eval cases, the latest score and recent runs. See [Evals](https://hubzoid.com/docs/guides/evals) | Read-only |
| **Feedback** | The ratings people gave its answers | Read-only |
| **Configuration** | Its declared settings with **Run checks**, its secret settings, and its channels | Settings and channels read-only |

> **Note: Browser editing is off by default**
>
> Settings shows an agent's files but does not change them unless `in_app_editing: true` is in `hubzoid.yaml`. Change them in the hub folder, or ask Claude Code or Codex. See [Why some screens are read-only](https://hubzoid.com/docs/settings/overview#why-some-screens-are-read-only).

## Give a teammate access

1. Open **Settings** → **Agents** → the agent → **Access**.
2. For someone without an account, select **Add user**. For someone who has one, select **Edit access** on their row.
3. Tick the capabilities they need. A tool capability includes **Use this agent**.
4. Select **Review changes**, check the summary, then save.
5. Share the chat address and their sign-in details yourself. Hubzoid sends no email.

The permission check changes at once, and the agents the person sees in chat follow it. Every saved change is recorded in **Activity** → **Audit log**.

## The Access tab

The **People** part, headed "People with access, and what each is allowed to do", lists the people with direct access.

**Searching the list, and every column and tag**

Search by name or email. Results are shown 20 at a time. Select a person's name to open their details under **People**, unless they have not signed up yet.

| Column | Contents |
| --- | --- |
| Person | Name, email and account status: **Active**, **Not signed up yet**, **Awaiting approval** or **Blocked**. A legacy service identity reads **Legacy service identity**, and an "Everyone signed in" row reads **Public** |
| Capabilities | One tag per capability the person effectively holds here |
|  | **Edit access**, or **Remove** on an "Everyone signed in" row |

| Tag | How the capability is held |
| --- | --- |
| A plain tag, such as **Use this agent** | A direct grant in this agent |
| An orange tag | A capability marked sensitive |
| Ending in **· inherited** | Through organization administrator rights. Administrators appear on every agent with **Manage access · inherited**. Change it by setting their role under **People** |
| Ending in **· everyone** | Through an existing "Everyone signed in" grant |
| Ending in **· no longer available** | The capability was removed or renamed. Remove it under **Edit access** |
| **No access** | Nothing is effective here, for example because the account is blocked |

## Add user

**Add user** on the Access tab starts with one search, **Name or email**:

- **Someone with an account.** Pick them from the matches. A person who already has access here is tagged **Has access**. Picking someone opens their access in this agent, to change and save like any edit.
- **Someone new.** Enter their full email and choose **Create an account**.

To create the account:

1. Enter their **Name** and **Email address**. They sign in with this email. An email that already has an account is caught as you type, with **Edit their access**.
2. Organization administrators can add a **Phone** with the country code, so the person's WhatsApp and Telegram messages are recognized. It is optional.
3. Type a **Password**, or select **Generate** for a random one made in your browser. It must be at least 8 characters and at most 72 bytes. Or tick **Google sign-in only**, described below.
4. Choose capabilities. **Use this agent** is ticked to start with.
5. Select **Review changes**. The review, "Review the new user", shows the person, the agent and each capability. Select **Create account**.
6. The panel shows the chat address, their email and the password once, with **Copy sign-in details**. Share them yourself. The password is never stored or logged, and it is cleared when you select **Done**.

**Adding users from People, roles and Google sign-in only**

**Add user** on the People page works differently: the person sets their own password with a one-time sign-in link. See [Add user on People](https://hubzoid.com/docs/settings/people-and-activity#add-user-on-people). Agent administrators add users here, on the Access tab.

New accounts have the normal user role. Make someone an Administrator later from their details under [People](https://hubzoid.com/docs/settings/people-and-activity).

**Google sign-in only** creates an account with no password. The person selects Google on the sign-in page, and Hubzoid links that sign-in to the account by email. It can be ticked only when Google sign-in is set up with `OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true`. Otherwise it is disabled with a hint. When Google sign-in is limited to some domains, only those addresses are accepted. See [Authentication](https://hubzoid.com/docs/deploy/authentication).

**What each result panel means, and access before sign-up**

Every result says exactly what exists:

| Panel title | What happened | Next step |
| --- | --- | --- |
| **User added** | The account exists with the access you chose | **Done**, or **Open their details** |
| **This user already exists** | Nothing was created or changed | **Edit their access** opens the editor with their current access plus your choices |
| **Account created, access not granted** | The account exists without access. Its sign-in details stay on screen | **Try again** grants the access to that account. It is never created twice |
| **Not confirmed** | The server did not confirm the result | **Try again**. If the first attempt made the account, the panel says so |
| **Nothing was created** | The request was refused, for example for a capability you may not give | **Back to the form** |

To give access to an email before its account exists, for example someone who will first sign in through single sign-on, use the server: `hubzoid grant priya@example.com use_hub ./my-hub`. Until they sign in, their status reads **Not signed up yet**.

## Edit access

**Edit access** opens the editor for that person, titled "Edit access", or "Give access" for someone with no access here yet. From a person's details under **People**, **Edit access** next to an agent, or **Add an agent** for one they can't use yet, opens the same editor, starting with **Use this agent** ticked.

**Capability groups, labels and blocked people in the editor**

The editor shows the person, their account status and **View profile**, then **Capabilities** in groups. Empty groups are hidden. Groups start collapsed except Hub access, and their header says what they hold, for example "Restricted tools · 2 selected".

| Group | What it holds |
| --- | --- |
| Hub access | **Use this agent** (`use_hub`) |
| Restricted tools | The hub's `restricted/<capability>.py` modules |
| Connectors | **Connect** or **Use** and the app's name, one per connector the agent offers (`connector_<id>`), and **Start work from** one per channel (`channel_<id>`) |
| Administration | **Manage access** (`manage_access`) |
| Hubzoid tools | Built-in capabilities, such as **Save shared knowledge**. Under **Workflows**: **See workflows and runs**, **Run and control workflows**, **Schedule reports for themselves**, **Share reports with the company domain** and one **Run** per report the agent offers in chat. Under **Access control**: **Manage access from chat** |
| No longer available | Grants whose capability was removed or renamed. They can be removed, never granted again |

Each capability shows a **Sensitive** tag where declared, and a short status when it cannot run yet, such as "Jev key missing" or "Not checked". Permission and configuration are separate: you can grant a capability before its setting exists, and adding a setting never grants anyone access. The question mark beside a capability explains what it does and why it is locked.

| Label | What it means |
| --- | --- |
| **Required** | **Use this agent** stays ticked while any other capability is ticked. **Remove all access** takes everything away |
| **Included** | It comes with **Use this agent** and has nothing to grant |
| **Inherited** | Held through organization administrator rights. Change it under **People** |
| **Outside your access** | You are an agent administrator and do not hold this capability here yourself |
| **Admins only** | Only organization administrators can grant it, such as **Manage access from chat** |
| **Locked** | Another rule applies, such as your own access or an administrator's. The help button says which |
| **Public** | **Use this agent** is held through "Everyone signed in". A direct grant keeps access if that grant is removed |

A blocked person gets a warning, and new capabilities are locked while existing ones can still be removed. **Remove all access** removes **Use this agent** and every capability with it, in one request. **Cancel** with unsaved edits asks before discarding them.

### Delegating an agent

An organization administrator ticks **Manage access** under Administration for a person. They become an agent administrator for this agent only. They see it under **Agents**, **Activity** and **Team schedules**, add users with access to it, and can chat with it. Restricted tools still need their own grants.

**What an agent administrator cannot do**

An agent administrator grants or removes only capabilities they hold in that agent themselves, never **Manage access** or **Manage access from chat**. They cannot change their own access or an administrator's, remove "Everyone signed in", approve sign-ups, reset passwords, change roles, delete users or add connectors. The server checks every change.

### Sensitive capabilities

A capability is sensitive only when it is declared so. For a restricted tool, declare it in the hub:

```yaml title="my-hub/identity/permissions.yaml"
payroll:
  label: Run payroll
  description: Process employee payroll and view salaries.
  sensitive: true
```

**Which other capabilities are sensitive**

That file labels restricted tools only. Built-in capabilities declare their own, as **Share artifacts publicly**, **Run and control workflows** and **Manage access from chat** do. Connector capabilities are sensitive. When a change grants a sensitive capability, the review warns "This grants a sensitive capability" and names it.

## Review and save

Nothing is saved while you tick boxes. **Review changes** shows the person, the agent, what is **Adding** and **Removing**, and a warning when **Use this agent** is removed or a sensitive capability is granted. Select **Back** to adjust, or **Save change** (**Save N changes**) to apply. When the change removes **Use this agent**, the button reads **Remove access**.

**When a save conflicts or is not confirmed**

The whole change is sent in one request with the access revision you loaded. Either every change applies or none does:

- If someone changed access after you loaded the page, the panel reads "Nothing was saved" and Settings reloads the current access so you can review again.
- If the response is lost, the panel reads "Save not confirmed", because the change may have applied. Settings reloads the access, and **Reopen** opens the editor again.
- After a successful save the notice reads "Access updated".

## Workflow permissions

The **Workflow permissions** part of the Access tab decides who may do what with each workflow. It is the same policy as `hubzoid workflow-access` and its `workflows/access.yaml` format.

![The Access tab on Workflow permissions. All workflows: admin@localhost may Run, Pause and cancel, Manage access as organization administrator. Monday brief, a markdown workflow: Nobody has access given here. Repeated requests: everyone who uses this agent may run and schedule their own. Below, Check someone's access and Edit as text.](https://hubzoid.com/docs-assets/app/agent-permissions-light.webp)

Give a person or everyone in the agent an action on one workflow or on all of them.

**Every workflow action**

| Action | What it allows |
| --- | --- |
| **Run** | Start it now |
| **Schedule** | Set it to repeat for themselves. Needs Run |
| **Edit**, **Create** | Propose changes to it, or new workflows, reviewed before they apply |
| **Review changes** | Review proposed changes to it |
| **See definition**, **See runs**, **See results** | Read how it works, see when it ran and how it went, or open what its runs produced when shared with them |
| **Pause and cancel** | Pause or resume its schedule, cancel or retry runs |
| **Manage access** | Change who may use it |

Select **Give access** under a workflow, or under **All workflows** for every workflow including new ones. **Check someone's access** answers whether one person may take one action, and why. **Edit as text** shows the policy as YAML to copy. Editing the file alone changes nothing: apply it with `hubzoid workflow-access apply`.

## Everyone signed in

Access goes to named people. Nobody can create access for everyone who can sign in, administrators included. Settings has no control for it, and `hubzoid grant '*'` is refused.

An agent that was open to everyone under an older release keeps that access as an **Everyone signed in** row, with a notice above the list. It keeps working until an organization administrator removes it. To replace it with named access:

1. Give the people who need the agent their own access, with **Add user**, **Edit access** or **Add an agent** under **People**. Give the account your workflows run as access the same way.
2. Select **Remove** on the **Everyone signed in** row. The confirmation says how many people open the agent only through it.
3. Confirm with **Remove access for everyone**.

**The server command, and company links**

On the server, `hubzoid revoke '*' use_hub --hub my-hub ./my-hub` does the same. An agent open to everyone signed in cannot have company links for its reports.

## Connectors

The **Connectors** tab lists the apps this agent offers, so it can use people's own accounts or one company account. A connector is registered once for the deployment and offered in each agent that lists it.

**Every column on the Connectors tab**

| Column | Contents |
| --- | --- |
| Connector | The app's name, id and server address |
| Sign-in | **OAuth** when each person signs in, **Shared key** for one company key, or **No sign-in** |
| Tools | How many tools are allowed, or **All tools** |
| Connected | How many people are connected |
| On | Whether the connector is switched on |

With browser editing on, organization administrators use **Add connector**, **Test**, **Edit**, **Stop offering** and **Delete connector** here. With it off, the tab is read-only. Offering a connector grants nothing: people also need its **Connect** or **Use** capability, and each person connects their own account under **Connected accounts**.

**Servers from the hub folder**

Below the list, **From the hub folder** shows the servers in `connectors/.mcp.json`, read-only, with **Ready** or **Missing settings**. See [Tools and connectors](https://hubzoid.com/docs/guides/tools-and-connectors).

## Blocked people

Settings does not block people. Someone can still be blocked by a block from an older release or through the management API.

**Why blocked rows appear, and lifting a block**

A block removes every direct grant, so blocked people usually no longer appear on Access tabs. Rows marked **Blocked** that do appear are usually accounts that were removed or can no longer be found, and their capabilities read **No access**. An organization administrator lifts a block with **Reactivate** in the person's details. See [People and activity](https://hubzoid.com/docs/settings/people-and-activity).

## Related

- [People and activity](https://hubzoid.com/docs/settings/people-and-activity): Accounts, roles, two-step sign-in, deleting users and the audit log.
- [Runs](https://hubzoid.com/docs/settings/runs): The Workflows tab, who each workflow runs as and each run's steps.
- [Restrict a tool](https://hubzoid.com/docs/guides/restrict-tools): Create a restricted capability and grant it from start to finish.
- [Tools and connectors](https://hubzoid.com/docs/guides/tools-and-connectors): Add Python tools and MCP servers, and let people connect their own accounts.