Governance & policies

Governance is where you define the rules the agent follows for your organization. Rules are written in per-scope YAML, combined in layers (with deny-wins), and resolved into an effective policy the agent receives on every session. For the complete mental model, see Organizations & policies.

The governance dashboard

The Governance page (/org/governance) opens with a statistics panel and gives access to the per-scope editors and the simulator:

Page	Scope
Organization Rules	Rules for the entire organization.
User Type Rules	Rules by user type (premium/full).
Profile Rules	Rules by profile.
Skill Group Rules	Rules by skill group.
Policy Simulator	Simulates the effective policy of a combination.

Each editor includes a YAML field and a Validate button, which checks the syntax and shape of the rules before saving.

The YAML schema, field by field

For the complete schema of what you paste into these editors — the required envelope, each policy block explained, and ready-made recipes to allow or block tools, execution, PII, and more — see Guardrails & the rules schema.

How the layers combine

The layers stack by precedence (deny-wins): each level can restrict, never expand the baseline.

The policy is assembled from the most general layer to the most specific:

1. Platform — the baseline, defined by NNumbers.
2. Organization — your company's rules.
3. User type — premium / full.
4. Skill group — rules by group.
5. Profile — the most specific, tied to the person.

Deny-wins: you only restrict

The layers combine under deny-wins. A more specific level can restrict what comes above it, never expand. The organization layer, for example, can only tighten the platform baseline — not relax it. The result is the effective policy delivered to the agent.

What the effective policy controls

The resolved policy governs several dimensions of the agent's behavior:

Dimension	What it defines
Output	Response format and limits (for example, a token cap).
Tool	Which tools the agent can use.
Execution	Command and local-skill execution; writes outside the workspace.
Content	Language, tone, and rules about the generated content.
Data	Handling of sensitive data.
Interaction	How the agent interacts (for example, when it asks for confirmation).

The Execution dimension is where the per-user overrides (in Users & roles) and the per-profile permissions (in Profiles) enter the combination.

Model allow-list

The list of models that appears to users (AllowedModels) is also part of the policy. When the organization uses its own keys, the models made available go through Manage models in BYOK: a model must be registered on the key and on the allow-list to be used.

Single-model org

In an organization that exposes only the primary model, the allow-list is effectively nnumbers. The default model (nnumbers), the code specialist (nnumbers-code), along with automatic routing, follow what the policy allows. See Models.

The policy simulator

The Policy Simulator resolves, on demand, the effective policy for a combination of user type, group, and profile. Use it before applying a broad change to verify the deny-wins effect — especially to confirm that a restrictive rule hasn't closed off more than you intended.

Validate, simulate, then apply

The recommended cycle: edit the YAML → Validate → simulate the affected combination → save. This way you avoid surprises in production (for example, a profile that stops seeing a skill).

See also

🛡️Guardrails (YAML schema)

The rules schema field by field, with allow/block recipes.

Open →🏢Organizations & policies

The complete concept of policy and layers.

Open →🔑BYOK

Where the model allow-list is registered.

Open →🎭Profiles

The most specific policy layer.

Open →🔒Security & privacy

The trust model behind the rules.

Open →