Knowledge tree
Offensive Security
Shells
File Transfer
Web Applications
Agent Permissions
An agent can decide that it needs to read a file, send an email, or run a command. That decision should not grant it authority to do so by itself.
Permissions are the controls that determine which actions can move from a model decision to a real operation. They can apply to a specific tool, require approval, constrain which identity or credential is used, or cause the system to reject an operation even when the model requests it correctly.
This introduces an important separation: capability and authority are not the same thing. The model being able to express an action does not mean it is authorized to produce its effect.
Capability and authority
A tool expands the actions the model can request. The Agent Harness exposes that capability to the model and turns an accepted tool call into a real operation.
A permission boundary can exist between those steps.
For example, an agent may know about a send_email tool. The model can produce a valid call with a recipient, subject, and body, while the harness can still:
- Allow it directly.
- Request approval.
- Deny it.
- Execute it under an identity that lacks permission to send.
- Apply an additional policy to the recipient or operation.
Looking only at the available tools therefore does not describe the agent’s real authority.
From a security perspective, the complete path matters:
requested action → permission control → executing identity → reachable resource → effect
A prompt injection can alter the model’s decision. Permissions determine what that decision can achieve afterwards.
Permission gates
Agentic systems can place controls in front of particular actions.
A configuration may allow low-impact operations automatically while stopping others for approval. It may also disable a tool entirely or apply rules to particular uses of it.
The terminology depends on the harness. Some products expose policies equivalent to allow, ask, and deny; others combine execution modes, administrative configuration, and per-action approvals. The principle is the same: the model requests an action and an external component decides whether it can run.
That control is deterministic with respect to the rule being enforced. An instruction inside the prompt may convince the model to request a different operation, but it does not by itself change a deny rule enforced by the harness.
Approval
Human approval adds another decision before the effect.
If an action requires confirmation, the agent can explain that it needs to send a message or modify a resource and wait for a person to allow it. This is useful when intent cannot be decided from a static policy alone.
But approval is not the same as least privilege.
Approving an operation once does not necessarily reduce the authority of the credential behind it, and an interface that asks for confirmation continuously can turn approvals into a routine click. Approval works best as a gate for decisions where human context matters, rather than as the only boundary in front of an excessively powerful capability.
Effective capability
Permissions need to be analyzed according to the effect the agent can produce, not only the name of each tool.
Suppose an agent has:
delete_file.bash.
The policy denies delete_file.
That prevents the agent from using that particular path. It does not necessarily prevent the file from being deleted: bash can run rm.
The same pattern appears with other capabilities. Blocking a dedicated web-access tool does not remove web access if a shell can run curl or wget and the runtime still has network connectivity. Restricting a specific Git operation does not necessarily prevent the same effect if Bash, the git binary, and suitable credentials remain available.
Therefore:
denied tool ≠ denied capability
A permission boundary is effective when it covers all relevant paths to the effect it is intended to control.
This makes generic tools particularly important. A narrowly scoped tool usually exposes a limited set of effects. A shell, an authenticated browser, or a generic HTTP client can represent many different capabilities behind one interface.
From a pentesting perspective, the useful inventory is the set of effects reachable through any available path. The list of allowed tools is only part of it.
Delegated identity
Many agent actions execute on behalf of another identity.
An agent working with GitHub, Gmail, Slack, or an MCP server may use a credential associated with a user, service account, or application. That identity has its own permissions in the target system.
The model does not automatically receive all authority that the service supports. It receives the authority it can exercise through the credentials and operations the system has delegated to it.
For example, a token that only allows reading email can make a send_email call fail even if the tool exists and the permission control allows it. With a credential that also permits sending, the same model decision can produce an external effect.
Scopes are a common way to express part of that authority. In OAuth-based systems, including MCP over HTTP, the server can validate which identity presented the token and which scopes it carries before allowing an operation.
Effective authority can be viewed as:
available tool → allowed execution → presented credential → resource permissions
If any layer rejects the operation, that path does not reach the effect.
The opposite can also happen: an excessively powerful credential can greatly increase the impact of a bad decision even when the original task needed only a small subset of its permissions.
Example: email agent
Suppose an agent receives this task:
Summarize the pending emails that require my attention.
It has two capabilities for doing so:
- Read email.
- Send email.
One retrieved message contains an indirect prompt injection that tries to convince the agent to forward information from other messages to an attacker-controlled address.
The prompt injection occurs when that untrusted content causes the model to request an action outside the user’s intent. Permissions then determine whether the request can execute.
If send_email is disabled, the manipulated decision cannot use that tool. If sending requires approval, the operation stops before execution and the user can reject it. If the credential is read-only, the email service should also reject the send.
If, however, the agent is automatically allowed to send messages and operates under an identity that can do so, the same manipulated decision has a path to an external effect.
The complete chain is:
attacker-controlled email → manipulated decision → send request → permission control → delegated identity → external email
The attack does not fundamentally change because the model uses a different tool or API. What matters is whether an authorized path exists from the decision to the effect.
This scenario also shows why blocking only send_email may not be sufficient in a broader architecture. If the agent retains an authenticated browser, a shell with access to an email API, or any equivalent capability, those routes need to be checked for the same outcome.
Least privilege and blast radius
The authority granted to an agent should start from the task it needs to perform.
If an agent only has to summarize email, it needs to read messages. The ability to send them, delete them, or modify mailbox rules expands its authority without being required for that task.
The difference can be expressed simply:
required authority < granted authority → unnecessary blast radius
This matters even when the model behaves correctly most of the time. A prompt injection, a reasoning error, or an ambiguous instruction can only produce effects through the capabilities the system places within reach.
Least privilege does not remove those failures. It reduces what they can achieve.
The same principle applies to identity granularity. A credential restricted to one repository exposes a different surface from one with write access across an organization. A read-only email token has a different blast radius from a complete user session.
When evaluating an agent, it is useful to compare:
- What the task requires.
- Which actions the agent can request.
- Which alternate paths can produce the same effect.
- What authority the identities behind those paths actually have.
The difference between the first and fourth points describes much of the unnecessary blast radius.
Permission boundary and execution boundary
Permissions do not fully describe what can happen after an action starts running.
A harness may authorize bash to run npm test. That decision answers whether the command may start.
Once started, the process may be able to access other files, environment variables, processes, or network connections depending on the environment in which it runs. Those capabilities belong to another boundary.
Approval and sandboxing often appear together in real systems, but they answer different questions:
Permission boundary: may this action start?
Execution boundary: once it starts, what can its execution actually reach?
Sandboxing & Egress covers that second boundary: what execution can reach and how it can communicate outside the environment.