Policies
What a repository's, your team's or your organisation's policy decides, how it caps your settings, and where you see it.
A policy sets the limits agents work within: which agent tools and model providers are allowed, how much they may do without asking, what may leave the machine, which network destinations they may reach, and which branches are protected. A policy is a ceiling: no setting, at any level, can loosen it. It only ever narrows what your settings allow.
Where a policy comes from
| Source | Where it lives |
|---|---|
| A repository | Its .mojoup/policy.json, committed with the code. |
| Your team hub | The team's rules, imported from a repository's policy and published by the hub's owner. Members pull it. |
| Your organisation | Published by your organisation, when you are signed in to one. |
When your organisation publishes a policy for a repository, the workbench writes it as that repository's .mojoup/policy.json and keeps a fingerprint of it. If the file is then edited or deleted, the workbench keeps enforcing the organisation's copy and fetches it again: a local edit cannot loosen it.
See what applies
Open Settings → Security (under Governance). The Repository policy group shows the open repository's policy:
- enforced, no policy file or invalid — ignored (a file that does not parse is ignored with a warning, never half-applied);
- whether secrets and personal data are redacted, and whether a local classifier checks prompts;
- a plain summary of each rule, for example "No .mojoup/policy.json — nothing is enforced beyond your settings."
Choose Edit policy (or Create policy) to edit the repository's own file.
Across Settings, a setting your policy decides says so: Managed by your organisation or Managed by your team. "A value its policy locks cannot be changed on this workbench, a project or a repository."
What a policy can decide
| Area | What it controls |
|---|---|
| Agent tools and providers | Which agent tools (runtimes) and model providers may start at all. |
| Approvals | The highest permission mode agents may use (approvals.maxMode), and actions that always ask, even in Full access (approvals.alwaysAsk). |
| Remote approvals | Which risk levels may be approved from another device such as your phone. High-risk approvals from a remote device are refused unless the policy allows them. |
| Data-loss prevention | What happens when a prompt holds secrets, personal data or a prompt-injection attempt: allow, redact, block or ask. |
| Network | Which destinations agents, tool servers and the built-in browser may reach. |
| Git | Protected branches, and whether changes must go through a pull request. |
| Sandboxing | Whether agents must run in a sandbox on a node (agents.sandbox). See Sandboxing. |
| Tool servers, secrets, teams, settings | Which tool servers may run and whether they ask first, which secrets agents may see, and settings the policy sets or locks. |
When a policy lowers an agent's permission mode, the workbench tells you: for example "Your organisation's policy allows at most Auto here, so this agent runs in Auto instead of Full access."
Permission modes
Each agent runs in one of four modes, chosen in the Chat composer's Access picker and capped by policy:
| Mode | What it does |
|---|---|
| Supervised | Ask before commands and file changes. |
| Auto-accept edits | Edit files without asking. |
| Auto | Ask only for risky actions. The default. |
| Full access | Never ask. |
Data-loss prevention
Before a prompt leaves your machine, the workbench can clean it:
- Redact secrets before a prompt leaves the machine: credential shapes are replaced with
[redacted:…]markers. On by default. - Redact personal data too: email addresses, phone numbers, card numbers, IBANs and other identifiers.
- Custom redaction rules: your own patterns, which a repository can commit so they travel with the code.
- Classify with a local model: an optional local classifier (Ollama, LM Studio or the bundled local runner) that also looks for names, addresses, sensitive content and prompt injection, and allows, redacts, blocks or asks. A hosted model is never used as the classifier.
Prompts to a local model are never redacted: nothing leaves the machine.
The kill switch
Settings → Security → Remote control has a Kill switch that drops every remote connection to this workbench at once (the tray menu has it too). A policy can lock it on; then the card says "Remote control is kept off by" your organisation or team. On a team hub, the kill switch stops what the hub forwards.
Every change is audited
Every change, whoever or whatever asked for it (you, an agent, a routine or a remote device), is recorded in the audit log with who asked, what was done and to what. A policy refusal is recorded too.
Related
Skills and the catalogue
The skills agents load, the customisations you can add, and the teams, roles and templates your organisation or team shares.
Run a team hub on your own network
Make one workbench or node your team's hub over Tailscale or a VPN, invite people and devices, and share projects without going through Mojo Up.