---
title: Permission Policies (public)
description: Harness Runtime permission policies allow, require approval for, or deny the actions an agent takes, and set the filesystem and network access of the …
product: Managed Agents
url: https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/concepts/permissions/
last_updated: "2026-09-23"
---

> **For AI agents:** The documentation index is at [https://docs.digitalocean.com/llms.txt](https://docs.digitalocean.com/llms.txt). Markdown versions of pages use the same URL with `index.html.md` in place of the HTML page (for example, append `index.html.md` to the directory path instead of opening the HTML document).

# Permission Policies (public)

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](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/details/what-you-can-build/index.html.md) 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](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/concepts/approvals/index.html.md). |
| `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.

**Note**:

  Codex does not support `default: deny`; it falls back to `ask` silently.

## 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](https://docs.digitalocean.com/products/managed-agents/action-gateway/index.html.md) 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:

1. If more than one rule matches, the last matching rule in the list wins, and its decision applies.
2. If no rule matches, the action uses `permissions.default`.

Action Gateway evaluates its own tools differently, using [most-specific matching](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/tool-policies/index.html.md) 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](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/configure-permissions/index.html.md).

## 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](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/concepts/egress/index.html.md). 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_tools` on 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](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/reference/environment-spec/index.html.md). For worked examples, see [Configure Permissions](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/configure-permissions/index.html.md).