Teams
Administration
The slice of the estate a team owns, and what a team viewer is shown.
Every other account sees the whole estate. That is right for IT and security, who make the decisions. It is wrong for an engineering lead who needs to see what their own people run and has no business seeing anyone else's.
A team is a slice of the estate, made in the portal: the people and devices it covers. A team viewer account is shown the teams it is in and nothing else. Team viewers read. They record no responses or decisions, change no settings and see none of the pages that run the deployment: anything that needs a decision stays with IT and security. A team viewer can ask for one.
Teams are made by hand rather than read from a directory. Department fields, directory groups and MDM device groups are exactly what is most often missing or out of date, and a team built on them would be wrong in the same places without saying so. Rules (below) keep that from becoming a maintenance job.
Setting one up
Settings > Account: add the person with the role Team viewer.
Settings > Teams: Create team and name it.
Open the team:
Members: tick the team viewer accounts it is shown to.
What it covers: add people and devices.
Rules: device-name patterns and enrollment tokens.
Not in any team, further down Settings > Teams, lists the people and devices seen in the reporting window that no team covers, each with a team to add it to.
A change reaches a team viewer who is already signed in within a minute.
What a team covers
Entry | Puts in the team |
|---|---|
Person | the person, every device the identity map attaches to them, and their findings with no device (cloud sign-ins), under any spelling of them the identity map knows |
Device | that device, under every name it has reported under: key, serial, asset-tagged key, device name |
Device-name pattern | every device whose name or key matches. A glob ( |
Enrollment token | every device that enrolled with it, including those that enroll after the team is made |
A device is in the team if any entry puts it there. A team holds at most 20,000 entries.
A device follows its person. Re-map a laptop to someone else in the identity map and it moves to their team.
Rules place new machines on their own. An enrollment token per department, or a naming convention, places every new machine without anyone opening the portal. People and devices listed one by one do not scale past a few dozen; rules do.
An account in several teams sees them together.
An account in no team sees nothing. Being left out of every team is not a way into the whole estate, and nothing nobody has placed is shown to any team viewer.
What a team viewer sees
Findings are cut to the team before anything is derived from them, so every count, trend and register row describes the team, not the organisation beside a shorter list.
Shown, cut to their teams: Overview (with the teams they are in where the spend card would be), Tools, People, Devices, Personal accounts (with any response already recorded, read-only), MCP servers, Activity, AI register (decisions read-only, with a way to ask for one), Paste guard, Agentic AI.
Not shown: Grafana dashboard, Changes, Unrecognised observations, Tool registry, Evidence centre, Budget, Review queue, Detection sources, Coverage gaps, Enrolled devices, Enrollment tokens, Settings. These are the pages that run the deployment, and the ones whose data is the organisation's rather than a team's: history is recorded for the whole estate, and budget is the whole organisation's spend.
Hiding them is not the boundary. The portal refuses a team viewer every route that shows the organisation as a whole, and the receiver refuses a team viewer every admin route except its own session, password and display preferences, and asking for a decision. Refused by default is the point: a route added later without thinking about teams leaks nothing.
Asking for a decision
A team viewer cannot record a decision on a tool. On the tool's page in the AI register it can ask for one instead, saying what the team needs and why.
The request waits at the top of the AI register for every owner and admin, and AI register in the sidebar carries the count. If a webhook is set (Settings > Display & alerting), the request is posted there too.
Recording a decision on the tool answers everyone who asked. The asker sees the decision, who made it and when, on the same page.
An admin can close a request without recording a decision, with a reply the asker reads.
One waiting request per tool per account. A team viewer sees its own requests and nobody else's, because another team's note can name its people.
What it needs
The portal's own credential: PORTAL_TOKEN on the receiver and RECEIVER_PORTAL_TOKEN on the portal, the same value. The chart generates it; Compose reads it from secrets/portal_token. The receiver refuses a team viewer's session on the reads a page is built from, so the portal makes those reads with this credential and cuts the result to the team. It is not the admin credential: the receiver lets it read what a page is built from and record a finished day, and nothing else. Without it a team viewer's pages answer 503 naming the variable, and Settings > Teams says so.
Where the boundary is
The cut is made by the portal. The receiver holds the teams and refuses team viewers, but findings come from the log store, read with the portal's credential. A compromised portal can read what its credential reads - the estate and the stored log-store credentials - and change nothing; see How Nyxus is put together and the security guidance.
Grafana is not cut to a team. Its panels query the log store themselves. Team viewers are not given the embed, but anyone who can reach Grafana sees everything it shows, so do not give team viewers access to Grafana.
The tool catalogue is the same for everyone. It lists the tools that exist, not who uses them.
API
Through the portal, with an organisation-wide session. Any organisation-wide account can read; changes need an admin.
Method | Path | |
|---|---|---|
GET |
| every team, its members, and what it covers |
POST |
| create one: |
PUT |
| rename, or change the note |
POST |
| remove a team. Its members keep their accounts and see nothing until they are in another team |
PUT |
| replace the members: |
PUT |
| replace what it covers: |
GET |
| people and devices seen in the window ( |
GET |
| requests for a decision, waiting first: every request for an organisation-wide account, its own for a team viewer. |
POST |
| ask: |
POST |
| close one without a decision: |
The receiver routes behind them are described in How Nyxus is put together. Every change is an audit event naming who made it: team_created, team_updated, team_deleted, team_members_set, team_scope_set, and for requests decision_requested, decision_request_closed and decision_requests_answered.
Limits worth knowing
Not in any team is the reporting window. Something not seen in the window is not listed, and is placed the day it reports by any rule that matches it.
A person is matched by the name the identity map gives them. A person added under a name the map does not know brings only the findings reported under exactly that name.
Moving an account out of Team viewer takes it out of every team. Moving it back does not restore them.