Policy
Decide what every workbench and node may do, publish it for the organisation or chosen projects, and lock their settings.
A policy is one document that every workbench and node in your organisation pulls and applies as read-only overrides: which agents and model providers they may use, what happens to secrets and personal information, which approvals may come from a phone, how changes land in git, where agents may connect, and which tools they may use. People cannot loosen it on their machine. The console's Policies view edits it as plain-language sections; each section says in one line what it does now and opens into the questions behind it.
Administrators publish policies. In Mojo Up AI Cloud that is a team's owners and admins.
Publish a policy
Open Policies
In the console, open Policies. The Published list shows each policy with its identifier, revision, and whether it is the organisation default or for some projects. Choose one to edit it, or start from the empty form.
Name it and choose what it applies to
Give it a Name and an Identifier. Under Applies to, choose:
- The whole organisation: the organisation default, for every project that has no policy of its own;
- Chosen projects: tick the projects. Everything else follows the organisation's policy.
Answer the sections
Open each section and set what you need (described below). Reset to defaults starts the form again.
Publish
Choose Publish. The revision goes up, and workbenches and nodes apply it the next time they pull the policy. Until anything is published, each workbench keeps its own policy file.
To withdraw a policy, choose Remove beside it in the Published list.
The sections
| Section | What it decides | Defaults |
|---|---|---|
| Runtimes and Providers | The coding agents a workbench may start, and the model providers it may use. Empty means any. | Any runtime, any provider |
| Data Protection | What happens to secrets in a prompt or an answer, personal information, and text that tries to redirect the agent (prompt injection); which sensitivity levels never leave the machine; whether a classifier model checks content first. | Secrets: Redact. Personal information: Allow. Prompt injection: Allow. Never send: restricted. Classifier: off |
| Approvals | Whether low-, medium- and high-risk requests may be approved From anywhere or At the machine only; which decisions agents record need a person's approval; task labels that need a person's review before the task is finished. | Low and medium from anywhere, high at the machine only |
| Git | Protected branches agents never push to directly (patterns such as release/* work), and whether changes land through a pull request. | None protected, no pull request required |
| Remote Control | The ways in (this machine only, companion apps, the local network, through the organisation), a limit on what a paired device may do, encrypted connections only, keeping remote control switched off, and the idle timeout. | This machine, the local network and through the organisation; no limit; 60-minute idle timeout |
| Agent Containment | Whether agents run in a sandbox: Off, Where available, or Always (work goes only to machines that can sandbox it, and a workbench without one refuses and says why). | Off |
| Where Agents May Connect | Hosts always allowed, hosts never allowed, rules for particular destinations, and what happens to everything else. | Everything else allowed; breaking connections blocked |
| Tools Agents May Use | What each class of tool may do, unpublished tool servers, project rules, and whether it is enforced. See Tools. | Watching only |
Data protection decisions are Allow, Redact, Block or Ask the person. Sensitivity levels are public, internal, confidential and restricted. With a classifier on, you also choose where it runs and which model, how long a check may take (50 to 5000 milliseconds, 300 by default), and what happens when it cannot answer in time: Carry on, Ask the person or Block.
The last section, The Document, shows the policy as JSON, for anything a newer workbench understands that the form does not ask yet.
Where agents may connect
The simple form is two lists, hosts always allowed and hosts never allowed, and what happens to every other destination. Rules say more about one destination: which programs may reach it (for example only git to github.com), and for a web API or a tool server, which requests or tools.
AIOE decides a connection in this order:
- The machine itself, link-local addresses and cloud metadata services are never reachable.
- A host on the never-allowed list breaks the policy.
- The first rule whose destination matches decides: its programs, then its requests or tools.
- A host on the always-allowed list is allowed.
- Anything else follows what you chose for other destinations.
When a connection breaks the policy is your rollout lever: Block it, or Only record it, which lets the connection through and records it, so you can see what a policy would stop before you switch it on. Each rule can also say As the policy says, Block it or Only record it for itself. The always-unreachable destinations are blocked either way.
Try a Destination previews the decision for a host, program and request, using the same logic the machines use.
This section is enforced where agents run in a sandbox. A machine that cannot enforce it says so.
Governed settings
Beyond the policy, you can set any workbench or node setting for the whole organisation. Open Policies, then the Settings tab. Settings are grouped as the workbench groups them, with a search. For each one you set, choose:
- Locked: your value wins over every other layer, and people see the setting as read-only;
- Default: your value replaces the product's default, and people may change it.
Governed settings apply with or without a published policy, and nodes receive them too. A project's owners can override them for their project on the project's Policy tab; a project's value wins over the organisation's. The full list of settings is in Workbench settings.
Policy for one project
A project's owners set more on the project's Policy tab:
- governed settings for that project;
- tool rules, which can only make the organisation's stricter, never looser;
- the project's merge rules: how many approvals a merge needs, whether authors may merge their own, whether checks must pass, which ways to merge are allowed, and whether agents may merge;
- the project's own secrets.
Which enterprise teams may run in the project, and whether members may run their own, is set in the Teams panel on the project's Overview. See Projects.
Credentials stay out of the record
A secret that strays into an audit detail, or into an event or audit record a machine reports, is masked before AIOE stores it: credentials in URLs, bearer and API tokens, JWTs, private keys, key=value secrets, command-line passwords and fields named like credentials. Commit IDs and SHA-256 digests stay readable. This is a second line behind the workbench's own data protection, not a replacement for it.