Permissions
Giving an agent a tool does not mean every use of that tool should happen without review. Permissions let the agent move quickly where the risk is low and pause where a person should make the final call.
Reading and acting need different boundaries
Suppose the marketing launch agent is preparing a weekly campaign report. It needs to read analytics data, draft a summary, and post the result to the team channel.
Reading the campaign numbers changes nothing in the source system. Posting the report sends information to other people. You may want the first action to run immediately and the second to wait for approval.
Permissions let you express that difference before the agent starts the work.
Every action can run, ask, or be refused
When the agent wants to use a tool, the permission decision has one of three outcomes:
- Allow: The action runs without stopping for approval.
- Ask: The agent pauses and shows you the action before it runs.
- Deny: The action does not run.
For the launch agent, reading the analytics can be allowed, posting the report can ask, and deleting a campaign record can be denied.
These outcomes apply to actions, not to whether you trust the agent in general. One agent can have the freedom to gather information and draft work while still requiring a person for external or destructive changes.
A default policy covers the agent
The agent's policy gives every tool a starting permission. Agenta provides four policies:
| Policy | What happens |
|---|---|
| Allow reads | Read-only actions run; other actions ask. This is the default. |
| Allow all | All actions run without asking. |
| Ask | Every action waits for approval. |
| Deny all | Every action is refused. |
Allow reads fits many interactive agents. The launch agent can gather campaign data and prepare the report, then pause before it posts.
You can override the policy for a connected-app or custom tool. A tool set to Allow, Ask, or Deny follows that choice; a tool set to Inherit follows the agent policy.
This gives you a broad default and a small number of deliberate exceptions. You might keep Allow reads for the agent, always allow the internal review-task tool, and always ask before the channel-posting tool.
An approval shows the proposed action
When an action needs approval, the run pauses at that point. Agenta shows the tool the agent wants to use and the arguments it plans to send.
For the launch report, you can review the destination and message before anything is posted.
- Choose Approve and the action runs. The agent continues from where it paused.
- Choose Deny and the action does not run.
- If this is an action you expect to approve in the future, you can choose to always allow that tool for the agent and commit the change.
The approval is part of the run, not a suggestion hidden in the instructions. Permissions enforce the decision even when the agent believes the action would be useful.
Chats and automations need different preparation
In a chat, you are present to answer an approval request. That makes Ask a useful boundary for actions you want to inspect case by case.
An automation runs without an active chat. Before scheduling the launch report, decide which required actions may finish unattended. If posting is meant to happen automatically, that tool needs permission to run without waiting for someone in the playground.
This does not mean every automation should use Allow all. A focused set of tools with explicit permissions is easier to review. Allow the actions the job needs, deny actions it should never take, and remove tools that do not belong to the job.
Permissions and the execution environment solve different problems
Permissions decide whether a tool call may proceed. The execution environment decides where code and tools run and what the sandbox can reach.
Use both when the agent handles sensitive work: permissions for human-control boundaries, and sandbox settings for filesystem and network boundaries. The detailed settings belong in the guide.
Continue with the guide
Control what an agent can do shows where to set the default policy, override one tool, review an approval, and configure the execution environment.
Related concepts: