dful.
Dful Dark
Theme
Browse notes
On this page

Agent Permissions

An agent's real authority when an action passes through tools, policies, approval, and credentials with permissions of their own.
Updated 6 Oct 2026

A model can decide that it needs to read a file, send an email, or run a command. Turning that decision into a real effect depends on controls outside the model: which tools are available, which policy allows them to run, and which identity executes the operation.

Agent permissions are that boundary between a requested action and an authorized one.

Capability and authority

A tool expands the operations a model can request. The Agent Harness receives the tool call and can allow it, request approval, or deny it before the operation reaches the runtime or an external service.

Suppose a send_email tool exists. A valid call can still meet several controls:

  • The tool is allowed for that task.
  • The operation requires user approval.
  • A rule limits recipients or message types.
  • The credential is read-only and the service rejects the send.

The tool list describes capabilities exposed to the model. Real authority comes from combining those capabilities with policy and identity.

Approval

Human approval is useful when intent depends on context. An agent can prepare a message and stop before sending it so a person can inspect the recipient and content.

That control does not reduce the permissions of the credential behind the operation. If the account can delete an entire repository, approving one specific action does not turn it into a lower-privilege identity. Approval and least privilege therefore address different problems.

Effective capability

During an assessment, the useful question is the effect that can be reached, not only the name of each tool.

If an agent has both delete_file and bash, blocking the first path does not necessarily prevent file deletion: the shell can run rm. The same applies to a web tool when Bash still has curl, or to a dedicated Git operation when the git binary and suitable credentials remain available.

denied tool ≠ denied capability

Denied tool, reachable capability The delete_file route is denied and stops before the target. A separate route through bash and rm remains available and reaches the same target file. delete_file Permission denial bash rm Target file Same final effect DENY Denied tool, reachable capability The delete_file route is denied and stops before the target. A separate route through bash and rm remains available and reaches the same target file. delete_file bash Permission denial rm Target file Same final effect DENY
Figure 1. Denying one tool removes that route, but the capability remains if another available interface can produce the same effect.

Generic interfaces deserve particular attention. A shell, authenticated browser, or generic HTTP client can represent many operations behind one capability. In pentesting, inventory the effects reachable through any of those routes and then check where policy is actually enforced.

Delegated identity

Many actions execute with a credential associated with a user, service account, or application. That identity adds another boundary independent of the model’s decision.

For example, a send_email tool may be enabled and pass harness policy, while a read-only OAuth token should still make the service reject the send. With another credential that includes write permission, the same tool call can produce the effect.

Scopes express part of this authority in many OAuth systems, including MCP over HTTP. Evaluate which credential is presented and what it can do to the specific resource rather than inferring authority from the existence of the tool.

An overly broad credential increases the blast radius of any bad decision. A token limited to one repository or read-only email exposes a very different surface from a complete user session.

Example: email agent

An agent receives this task:

Summarize the pending emails that require my attention.

It needs read access to complete the task. Suppose it also has the ability to send messages and one retrieved email contains a prompt injection that tries to make it forward information to an attacker-controlled address.

Several controls can stop the path after the manipulated decision:

  • send_email is disabled for this task.
  • Sending requires approval and the user rejects it.
  • The credential is read-only and the service denies the operation.
  • Another policy blocks that recipient.

If the tool is allowed automatically and the identity has authority to send, the decision has a route to an external effect.

Blocking only send_email is also insufficient if the same agent retains an equivalent path, such as an authenticated browser or a shell with access to the email API. Permission review has to cover effective capabilities rather than only the most obvious interface.

Least privilege and execution boundary

Granted authority should start from what the task requires. An agent that only summarizes email needs read access; sending, deleting, or changing mailbox rules increases possible impact without helping complete that work.

A useful blast-radius review compares:

  1. Which effects the task requires.
  2. Which actions the agent can request.
  3. Which alternate paths can produce the same effects.
  4. What permissions the identities behind those paths actually have.

Permissions answer whether an action may start and under which authority. Once a process is running, another question remains: which resources can that code reach inside its environment. Sandboxing & Egress covers that execution boundary.

A harness may authorize bash to run npm test; the sandbox then determines which files, credentials, processes, and network connections that command and its subprocesses can use.

References