People and activity

People answers "who has access, and can their account use it?" Activity answers "who changed access, and what did people actually do with restricted tools?" Together they are the Console's audit trail. Accounts and sign-in live in the chat app, and access is decided in Hubzoid. Organization administrators can also add, approve and delete users under People, and the Console makes those changes in the chat app for them.

When to use thisCopy Anchor Link

Use People when you onboard or offboard someone, approve a sign-up, reset a password, make someone an administrator, review who holds a sensitive capability, or find out why a granted person still cannot use an agent. Use Activity when you need evidence: who granted something and when, who added or deleted a user, which calls were refused and why, or who paused a workflow.

The People pageCopy Anchor Link

People in the sidebar (#/people) lists everyone with access to the agents you manage. Add user is at the top for anyone who can create accounts, next to Refresh accounts for organization administrators.

Organization administrators see every identity Hubzoid knows: everyone who has been granted access, plus chat accounts recorded when they signed in, used an API key or appeared in an account refresh or sync. A user deleted in the Console is no longer listed. Agent administrators see only the people with a grant in an agent they manage.

Filters and the page number live in the address, and results are shown 50 per page. Refresh accounts reads the chat app's account directory again to update account states. It never creates accounts, and it needs the deployment's chat app service credentials.

On a gateway, a line under the heading reports the chat app visibility sync, which copies each person's agent access into the agent list they see in the chat app. Enforcement never depends on it. When it succeeds, the line says visibility is in sync and when it last ran. When the last attempt failed, a warning says recent access changes haven't reached the chat app yet and that access is enforced regardless. The periodic sync keeps retrying, and organization administrators can select Try again now. The line also says when no agent is managed yet, so there is nothing to mirror, or when no sync has run, with Run it now for organization administrators. hubzoid access sync does the same on the server. A standalone hub shows no line, because the edge checks each person's agent list directly.

Add user on PeopleCopy Anchor Link

Add user on People creates a new user with access in any of the agents you manage, in one step. It works like Add user on an agent's Access tab, with the same name, email, password and Google sign-in only fields, and these differences:

• Initial access lists each agent you manage as a collapsed section, with the same capability groups inside. Capabilities you may not give read Outside your access or Admins only and cannot be ticked. An agent that still uses legacy access takes no grants here.
• An organization administrator can create a user with no agent access yet. An agent administrator must choose access in at least one agent they manage.
• Review lists the new account, with the chat app's normal user role, and the access per agent. Create account creates it and shows the sign-in details once.
• If the email already has an account, nothing changes and Edit this user opens their details.

Only an organization administrator can create an account for an email whose earlier account was deleted.

Account statusesCopy Anchor Link

Every row shows one status. The same labels appear on the Access tab.

The status is chosen by the first rule that matches: an administrator block, then *, then a legacy service identity, then no chat account, then pending approval, then a chat account missing from the directory, and otherwise active.

Behind the status, Hubzoid keeps two independent markers per person. Enforcement treats them as blocked when either is set.

A failed or partial directory read never marks accounts unavailable.

A user's detailsCopy Anchor Link

Details, or the person's name, opens their details at #/people/<email>. The panel is titled with their name.

• Email is the identity that grants attach to. Whoever signs in with it holds the access.
• Status is the account status. Its tooltip explains what it means.
• Role is User or Administrator. For a sign-up awaiting approval, Awaiting approval with Approve takes its place.
• Password offers Reset password. For a user created with Google sign-in only, it says instead that they sign in with Google and their password is managed through Google.
• Access by agent lists, for each agent you manage, the capabilities they effectively hold there. Edit access opens that agent's editor on this person. Add an agent picks an agent they can't use yet and opens its editor with Use this agent ticked. It is not offered for a blocked user.
• The … menu at the top holds Delete user.

Role, Password and the … menu are for organization administrators, on a person with a chat account. They need account management set up on the server, as for Add user. Nobody can change their own account here. Change it in the chat app's own settings. The Console's service account is refused as well. Agent administrators see the role as text and can edit access in the agents they manage. Every change is recorded in Activity.

Approve a sign-upCopy Anchor Link

When someone signs up and the chat app holds the account for approval, their status reads Awaiting approval. Select Approve in their details to give them the chat app's normal user role. Approval gives no agent access by itself, except through an existing "Everyone signed in" grant. Give them access with Add an agent or from an agent's Access tab.

Reset a passwordCopy Anchor Link

Reset password opens a password field with Generate. Set password applies it and shows it once with Copy, so you can share it with the person directly. The chat app signs them out of their other sessions. A Google-only user has no password to reset here.

Role: User or AdministratorCopy Anchor Link

There is one Administrator role. Administrator makes the person an organization administrator in Hubzoid, with Manage access for the whole deployment, and an administrator in the chat app, together. User clears both. Choosing a role asks you to confirm with Make Administrator or Make User.

• The chat app's role is set first, then Hubzoid administration. If only one side changes, the panel says which side is set and offers Try again, which finishes the change.
• A user who is an administrator on only one side, for example one made an administrator in the chat app directly or with hubzoid grant on the server, shows Needs attention, and its tooltip says which side is set. Reading their details never changes either side. Choose a role to fix it.
• The last administrator, on either side, can't be made a User or deleted.
• A blocked or unavailable user can't be made an Administrator, and a sign-up must be approved first.
• Administration alone does not let someone chat with an agent or use its restricted tools. Grant those per agent.

Agent administrators have no role control.

Delete userCopy Anchor Link

To offboard someone, an organization administrator opens the … menu in their details, selects Delete user and types the person's email to confirm. This is a real deletion:

• Every grant the person holds, in every agent, is removed first. Then the chat account is deleted through the chat app, together with their chats, shared chat links and group memberships. Their chat app API keys stop working with the account.
• Kept: Activity history, usage records and artifacts they published. Their public artifact links stop working.
• The email is marked as removed, so it inherits nothing and the person no longer appears under People. Only an organization administrator can create an account with that email again.
• The last administrator can't be deleted.
• If the grants were removed but the chat account could not be deleted, the panel says so. Trying again finishes the deletion.

Nothing else needs doing in the chat app. The chat app does keep the deleted account's stored connection tokens in its own database.

People blocked in an earlier releaseCopy Anchor Link

The Console no longer offers Block or Reactivate. A person blocked in an earlier release stays blocked. They show as Blocked, are refused in every agent, including through an "Everyone signed in" grant, and new access for them is refused. Delete them, or have an organization administrator unblock them through the management API with an Open WebUI API key:

curl -X POST https://chat.example.org/portal/api/people/block \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{"subject": "priya@example.org", "suspended": false}'

Unblocking does not restore the grants the block removed, so grant access again per agent. The same applies to the safeguard that blocks an email when a different chat account signs in with it. Review that account before unblocking it, and never unblock one only because its email matches.

ActivityCopy Anchor Link

Activity in the sidebar (#/activity) covers every agent you manage. Each agent's Activity tab shows the same view for that agent alone. A switch at the top chooses one of two records.

Both records share these controls:

• Time range: Any time, Last 24 hours, Last 7 days or Last 30 days. The chosen range is fixed to exact start and end times in the address, so a shared link always shows the same window and new events never shift the pages.
• Agent, in the cross-agent view.
• Refresh, Reset filters and pages of 50 events.
• Columns When, What happened (a tag and a sentence), Agent in the cross-agent view, and Details, which opens Event details with the exact time in your timezone and copyable identifiers.

In the cross-agent view with no agent selected, organization administrators also see organization-wide events, such as account actions and administrator rights, listed with the agent Organization. Agent administrators see only events in their agents.

Access changesCopy Anchor Link

Every change to access writes a row to hz_access_audit in the same transaction as the change itself. Filter by Affected person's email, Changed by (email) and Action: Granted, Removed, Blocked, Reactivated, Paused a workflow, Resumed a workflow or Cancelled a run. Account actions have no Action filter of their own, but they appear in the list.

The actor tells you where the change came from:

Tool decisionsCopy Anchor Link

Every call to a restricted tool writes a row to hz_access_decisions as it is decided. Filter by Outcome (Allowed or Denied), Person's email, Tool and Channel, which is the surface value such as owui, mcp, slack-dm or workflow.

Rows read as "Priya used ledger_read in Finance Assistant via owui" or "Priya was denied payroll_run in Finance Assistant via owui". A call with no signed-in caller reads "Someone not signed in". Event details shows the time, outcome, person, tool, channel, agent and reason, and the list explains the reason in words:

Tools hidden from a caller produce no row, because nothing was called. See Identity and access.

Using People and Activity for auditsCopy Anchor Link

The same decision rows are available on the server with hubzoid audit, for example hubzoid audit ./finance --denied --limit 200.

Next stepsCopy Anchor Link

Read this page as Markdown