Teams

Fleet > Teams & policies controls who can use each managed machine, what every user machine should contain, and how each team can use shared capacity. People and organization membership remain managed in Msty Account.

See Policy hierarchy for how team, machine-type, access, shared-machine, and Guard rules combine.

Roles

• Owner has full organization control, including billing and other owners.
• Administrator manages machines, teams, people, policies, and organization settings.
• Team manager manages machines, people, policy, and audit data only for assigned teams.
• Member uses assigned user machines and shared machines allowed for their team.

An owner or administrator grants the team-manager role in Msty Account. A manager of several teams chooses the team when adding a machine. Managers cannot promote other managers or change billing, SSO, plan, or entitlements.

Set up a team

The team setup checklist follows this order:

1. Give the team Nexus access in Msty Account.
2. Add or assign its user machines.
3. Set a user machine policy, or explicitly choose no policy.
4. Compare machines and apply the policy where needed.
5. Assign each user machine to a person.
6. Optionally share larger machines with the team.

Selecting No policy gives people complete control of their own user machines. It is different from a policy with no selected items.

User machine policy

A user machine policy states what every machine in the team must have. It can cover:

• Msty Nexus Runtime version
• Local runtimes and update behavior
• CLI Proxy
• Models
• Presets and Smart Routes
• Online providers
• Tool integrations and tool profiles
• Data Protection policy and privacy model

The editor uses an online team machine as its example. Items copied from that machine keep safe configuration, not provider credentials or client-token values.

Saving a policy does not immediately modify machines. Select machines with policy gaps and choose Apply policy. Review the action list before starting; each machine reports progress through Activity.

Offline machines cannot be compared or updated until they reconnect. A person who can manage a policy area on their own machine can change it locally; the next comparison shows the drift, and Apply policy restores the required state.

Machine types and global policy

Machine types let one policy fit different hardware. An owner or administrator defines ordered organization-wide types under Machines > Machine types & global policies.

A type can match:

• Operating system
• Minimum or maximum memory
• Computer model text
• Chip or CPU text
• GPU name or minimum GPU memory

The first matching type wins. The final Everything else type has no rule, so every user machine has a result. A machine can also be pinned to a type by an owner, administrator, or its team manager.

Each type can have an organization policy. A team can then keep an area Same as team, use Team plus these, choose Only these, or set a single value for that type. Effective policy is calculated in this order:

1. Team base policy
2. Organization policy for the machine type
3. Team override for the machine type

For example, the team base can require a small model on every laptop while the Pro type adds a larger coding model.

Later layers change only the areas they name. See Policy hierarchy for inheritance, replacement, access precedence, and troubleshooting.

Assign people and controls

A user machine belongs to one home team and can be assigned to one person. A member opens only the user machines assigned to them. The desktop app can make this assignment when the member signs in on their machine.

Team settings decide which parts members can manage: online providers, local providers and models, routing, tools, access keys, and machine settings. A person's custom rule can replace the team default for that person.

Shared machines

A shared machine has one home team and can be shared with other teams. For each receiving team, choose:

• Whether the team can view, use, or fully manage the machine
• Whether it is reachable only on the internal network or also through approved outside access
• Which models or routes the team can use
• Whether the team can change configuration

A manager of the home team can change the machine and share it with other teams they manage. A manager of a receiving team can change that team's rule but cannot reconfigure the borrowed machine.

Use shared machines for centralized GPUs, online provider access, Smart Balancer targets, or larger local models. Keep at least one valid fallback when a route depends on a shared machine that is reachable only from the office network.

Managed Guard

Enterprise organizations can publish Guard policy by team. The control plane reduces and signs the relevant policy for each assigned machine, and Runtime verifies and enforces it locally.

If a governed machine has no valid team or current policy, synchronization cannot choose a safe result. Fix the assignment or policy instead of bypassing enforcement.

Audit and security boundary

Owners and administrators can review organization-wide changes under Fleet > Audit. Team managers see only events scoped to teams they manage.

Team policy never copies provider credentials, subscription sessions, client-token plaintext, prompts, responses, or tool payloads into the control plane. Review Security and Fleet Operations before enabling remote access or lobby walls.