Policy hierarchy

Nexus uses separate policy systems for required machine configuration, people's access, and request-time safety. They work together, but one does not replace another.

The three policy systems

Changing access does not install or remove anything. Applying required configuration does not grant a person access. Guard evaluates requests even when the machine's installed configuration matches policy.

Start with the machine's home team

Every managed machine has one home team.

• A user machine can be assigned to one person. Its home team supplies required configuration and member access rules.
• A shared machine has no assigned person. Its home team owns the machine and decides the maximum access another team may receive.

Moving a machine to another home team can therefore change its effective policy and who may administer it.

Required configuration hierarchy

For a user machine, Nexus resolves required configuration in this order:

1. Team base policy provides the starting configuration for every user machine in the team.
2. Organization policy for the machine type adjusts the configuration for hardware such as standard laptops, high-memory Macs, or GPU workstations.
3. Team override for the machine type makes that type different for one team.

The later, more specific layer wins only for areas it changes. Other areas keep inheriting from broader layers. A list area can add items to the inherited list or replace the list; a single-value area can inherit or set a value.

For example, a team base can require a small model on every user machine, the organization policy can add a larger model to high-memory machines, and one team's type override can require a different route pack for those machines.

The policy comparison labels the source as Team policy, Organization default, or Team override. Use that label to find the correct place to edit a value.

Matching and pinned machine types

Organization machine types are checked in order, and the first match wins. The final Everything else type provides a fallback. An owner, administrator, or the machine's team manager can pin a user machine to a type instead of using automatic matching.

Policy does not change a machine until you apply it

Saving policy changes the required state immediately, but it does not silently reconfigure machines. The comparison reports one of these outcomes:

• Matches policy: the machine has the effective required configuration.
• Out of policy: the machine differs and needs review or Apply policy.
• Could not be verified: Nexus could not complete the comparison, often because the machine is offline or timed out.

Review the dry run before choosing Apply policy. A manual machine change that differs from effective policy is drift and the next comparison reports it. Machine-specific configuration exceptions are not currently available.

Access hierarchy

Access is cumulative: every relevant boundary must allow the action. A narrower rule cannot grant more access than a broader role or ownership boundary permits.

1. Organization role sets the maximum authority. For example, a Viewer cannot make changes even if a machine rule says operate.
2. Administrative scope limits a team manager to the teams they manage. Owners and administrators can work across the organization.
3. Machine ownership or assignment determines whether the person can open the machine. Members normally open user machines assigned to them.
4. Team device rule lists the areas members may manage on their own user machines.
5. Person rule, when present, replaces the team device-area list for that person in that team.

A team manager's administrative access to a machine owned by their team is separate from the assigned person's access.

Shared-machine access

Shared machines use two sides of policy:

1. The home team owns the machine, configures it, and sets the maximum access it is willing to share.
2. A receiving team chooses its own access and connection rule within that maximum.

A receiving team's manager can change only their team's rule. They cannot move the machine, change its configuration, or grant more access than the home team allows.

Shared-machine access controls who may open or use the machine. It does not create a required-configuration policy for that shared machine.

Where Guard fits

Nexus Guard is evaluated at request time by Nexus Runtime. It is separate from installed configuration and Console permissions.

Depending on the organization policy, Guard can audit or block requests based on:

• Output and usage limits associated with local client tokens
• Tool names in inference requests
• Runtime-owned outbound connections
• Model source, revision, hash, or license evidence
• Managed logging, retention, usage, and network settings

Runtime verifies the signed policy locally, including during temporary loss of control-plane connectivity. When blocking enforcement is active and no valid policy is available, guarded requests fail closed.

Use required configuration when machines should have the same software and resources. Use Guard when requests must obey a safety or compliance boundary.

Diagnose an unexpected result

When a machine or person does not behave as expected, check in this order:

1. Confirm the machine's home team and, for a user machine, its assigned person.
2. Confirm the matched or pinned machine type.
3. Read the policy source shown by the comparison.
4. Check whether a team type override adds to or replaces the inherited area.
5. Check the person's organization role, the team device rule, and any person rule.
6. For a shared machine, check both the home team's maximum and the receiving team's rule.
7. Check Guard mode and the current signed policy if inference requests are denied.
8. Review Fleet > Audit to see who changed policy, access, assignment, or sharing.

See Teams for setup steps and Fleet Operations for policy status and administrative audit.