Skip to main content

Policies

A policy decides every request an agent makes: allow, ask or deny. Here: write one, test it without a model, and read its decisions.
Every output on this page is what the code printed when it was run. The model’s wording will differ on your run; the decisions will not.

Start from a profile, add a rule

A built-in profile plus the one rule you need:
Every issue_refund call now pauses for a person (Approvals). Or set "profile": "..." alone. The three profiles on the same four calls (the script is below):
lookup_order is your tool, search an MCP tool. A delete is high-risk, so interactive-dev’s ask_high_risk asks. Every profile rule: policy reference.

A rule

A rule:
Its effect is the list it is in: deny, ask or allow.

How a request is decided

1

A deny rule matches: denied

Deny wins over everything. The model is told the call was refused and why.
2

Otherwise an ask rule matches: a person decides

An ask outranks an allow. Adding an allow rule to a profile does not lift that profile’s asks; remove the ask rule, or write your own policy.
3

Otherwise an allow rule matches: allowed

4

Otherwise the mode decides

permissive allows, interactive asks, strict denies. The decision’s reason_code is unknown_capability and matched_rule_ids is empty.
matched_rule_ids lists every matching rule in the winning list.

Test a rule before you run

Build the request a tool call makes and ask the evaluator the agent uses. No model needed:
tool_provider: local, workspace, artifact, mcp (with tool_server), skill, sandbox or code. write_file fell through to strict mode. Put checks like these in your tests. The profile comparison above:

Three ways to give the policy

The whole policy in your code. Here, a strict policy that allows one tool and nothing else:
The tool never ran; the model was told why. (“No rule covers” means no rule matched this call: lookups only matches lookup_order.)
Auto-discovery. With neither policy nor policy_path, an omnicoreagent.policy.json or .omnicoreagent/policy.json in the project root is merged onto the profile. It can only narrow: its deny and ask rules are added, the stricter mode wins, and a wider allow is refused.

Read the decision

Each tool call in a trajectory has a governance list: trajectory["harness"]["governance"] has the policy_hash. An approved ask shows two entries: ask, then allow with approved.

Options

In agent_config["governance_config"]: All settings: agent settings reference.

When things go wrong

Raised by OmniCoreAgent(...). Pick one: the policy in code, or the file.
Raised on the first run. The file is in the workspace, or under a directory with one of the names the agent may write to (paths shortened here):
Move it, for example to policies/.
The file is outside project_root, which is the current directory unless you set it (path shortened here):
Set project_root to a directory that contains the file, or move it. Policy file not found: ... means the path is wrong; a relative path is read from the current directory.
Only JSON policy files are read:
An omnicoreagent.policy.json that the agent found on its own tried to allow something the profile does not:
A discovered file can only narrow. To widen what is allowed, pass the file explicitly with policy_path.
A rule’s shape is checked when the policy is built:
Each rule_id must be unique across the policy; the fields are those in A rule; the mode is permissive, interactive or strict.
mcp.server.start and mcp.server.connect are decided when the agent connects, outside any run, so there is nothing to pause. An ask there (as in interactive-dev) fails the connection:
Allow the servers you trust, by the name you gave them in mcp_tools: {"rule_id": "docs_server", "capability": "mcp.server.*", "target": {"mcp_server": "docs"}}. An allow does not lift a profile’s ask, so with a profile, also remove its ask rule:
The docs server now connects; any other server is still asked about, and so still fails to connect.

Next

Approvals

What happens at an ask: pause, decide, resume.

Policy reference

Every capability, and every rule of each profile.

Security model

How the policy fits with the sandbox, budgets and the rest.

Execution

Commands, skill scripts and code mode, and the capabilities they use.

Budgets

Limits that live next to the policy.

Sandbox providers

Where the agent’s commands run.