Codex does not support default: deny; it falls back to ask silently.
Permission Policiespublic
Last verified 23 Sep 2026
DigitalOcean Harness Runtime provides managed, hardware-isolated microVM sandboxes with built-in tools such as Chromium to run harnesses and execute arbitrary code. Rich lifecycle APIs preserve conversational history and working state across sessions, letting you pause, resume, and fork work to control costs and adapt to the nonlinear nature of agentic workflows. Scale complete agents such as Claude Code or use sandboxes independently for code execution, all through the same service. See What You Can Build for example use cases.
A permission policy is the permissions block of a Harness Runtime environment spec. It decides what the agent may do without interruption, what requires your approval, and what is blocked outright. The policy is the enforcement mechanism for agent behavior. Prompts, instructions, and tool selection shape what the agent tries; only the policy determines what it is allowed to complete.
Policy Decisions
| Decision | Behavior |
|---|---|
allow |
The agent performs the action immediately. |
ask |
The agent stops and waits for your approval. |
deny |
The action is blocked. The agent is told no and may try another approach. |
permissions.default sets the decision for any action no rule matches. Omitting it resolves to ask. Set it explicitly so the intended posture is visible in the spec, and prefer a restrictive default with targeted allow rules over a broad allow.
Omitting the permissions block entirely is different from setting a default. With no block, Harness Runtime sends no policy and the agent keeps whatever built-in default it ships with, which varies by adapter.
Rule Targets
A rule names the kind of action it applies to. Harness Runtime uses a taxonomy of built-in action types, including bash, file.read, file.write, web.fetch, the git.* operations, and mcp.
A rule can also name a specific tool on a specific MCP server by qualifying it with the server, as in do.actions/action_code, or name a versioned Toolbelt, as in do.actions/toolbelt:read-only@1. Qualified rules are how you express policy for Action Gateway tools.
Rules match literally. A deny on one command does not block a different command that accomplishes the same thing, and a deny on one path does not cover another route to the same file. Write a rule for each form you intend to control, then confirm the result on a live session before relying on it.
How a Decision Is Reached
For actions the agent takes natively, Harness Runtime evaluates rules in order:
- If more than one rule matches, the last matching rule in the list wins, and its decision applies.
- If no rule matches, the action uses
permissions.default.
Action Gateway evaluates its own tools differently, using most-specific matching rather than order. Do not assume rule order controls the outcome for a gateway-qualified rule.
Where Rules Are Enforced
Two different enforcement points read your policy, and they behave differently on the same decision.
Unqualified rules are enforced inside the sandbox, at the agent. This is where ask produces an interactive approval request you can answer.
Rules qualified with do.actions/ apply to the Action Gateway session attached to your agent. Gateway rules apply whether a tool is preloaded and called directly or reached through a meta tool.
For the claude-code and codex adapters, an explicit ask rule or permissions.default: ask delegates approval to Action Gateway. The gateway pauses the tool call, and the adapter presents an approval request. OpenCode and Cursor handle approvals through Harness Runtime instead. Verify approval behavior with the adapter you deploy; do not assume all adapters support the same prompts. See Configure Agent Permissions.
Enforcement Modes
A rule can declare how strictly it must be applied. strict requires the enforcement point to be able to guarantee the decision. best-effort accepts enforcement by the agent’s own cooperation. Deny rules default to strict; other rules default to best-effort.
A strict rule that the chosen adapter cannot hard-enforce fails the session at creation rather than starting an agent that would silently ignore it. This is intentional: a policy you believe is enforced but is not is worse than a session that refuses to start.
Filesystem and Network Access
Beyond per-action rules, the policy sets two sandbox-level controls.
permissions.filesystem is either read-only or workspace-write, with an optional list of additional writable paths. This is enforced by the sandbox rather than by the agent, so it holds even if the agent attempts a write another way.
permissions.network narrows outbound access for the agent. It can only restrict within the session’s egress policy. It never widens it, so a host an egress allowlist excludes stays unreachable no matter what the policy says.
What Is Not a Permission Boundary
Several things look like access controls and are not.
allowed_toolson an agent skill is advisory. It documents which tools a skill expects to use. It does not grant them and does not restrict them.- Tool selection is not disposition. Attaching a narrower set of MCP tools reduces what the agent can discover, but the permission policy still decides whether an attached tool runs.
- Instructions and prompts are guidance. An agent can be argued out of an instruction. It cannot be argued out of a deny rule.
- A policy does not reduce a credential’s scope. If a token can delete a repository, a deny rule in one session does not change that. Grant least-privilege scopes at the provider.
For the syntax and the full field list, see the environment spec reference. For worked examples, see Configure Permissions.