AI Agent Permission Management: Guardrails and Sandboxes

The content of this article was checked on October 2, 2026, against official documentation from OWASP, n8n and Dify, and materials from the Japan AI Safety Institute (AISI) and Japan's Ministry of Economy, Trade and Industry (METI). Features and plan conditions may change. Check the sources at the end for the latest details.

When managing AI agent permissions, the question is what happens when the AI makes a wrong decision. The wider its permissions, the wider the damage from errors or hijacking. Types of damage are explained in AI agent security.

Grant only what is needed

OWASP's “Top 10 for LLM Applications 2026” lists ways to prevent Excessive Agency. The basic rule is to keep tools, functions and permissions all to the minimum needed.

• Limit tools: if the agent does not need to fetch a URL's contents, do not give it that tool
• Limit functions: if it only summarizes email, give it read access only, without sending or deleting
• Avoid open-ended tools: instead of a tool that runs shell commands, build a tool that only writes to a file
• Limit permissions: if it only recommends products, give it read access to the product table only, with no writing or deleting

OWASP also recommends that the program, not the AI, decides whether to allow an action. Writing “do not delete anything” in the AI's instructions will not stop it when the instruction is broken. Not granting delete permission in the first place is the reliable way to stop it.

AISI's “Guide to Evaluation Perspectives on AI Safety (version 1.20)” also includes example evaluation items that check whether an AI agent can access only the information and tools it needs.

Accounts and authentication for AI agents

Authentication for an AI agent decides whose permissions it runs with. OWASP recommends that actions taken on a user's behalf run within that user's permissions, with the minimum privileges. For example, for a tool that reads a user's code, ask the user to grant only the minimum scope through OAuth.

• Create a dedicated account or API key for the AI agent, separate from people's accounts
• Keep API keys and tokens on the program side, not with the AI
• Do not put passwords or tokens in the AI's instructions (system prompt)
• Choose permissions in connected apps to match the features you use

A dedicated AI account makes it easier to tell from the logs who took an action. If a problem occurs, you can disable just that account or key. OWASP's “Agentic AI - Threats and Mitigations” points out that if an AI agent's persistent identity is stolen, attackers may gain long-term API access.

Guardrails: check inputs and outputs

Guardrails are mechanisms that check what goes into the AI and what comes out. Anthropic's guide notes that having one model do the main task while another screens for inappropriate content tends to work better than having the same model do both.

OWASP recommends checking the output format with code rather than another AI. Even so, output can be in the right format and still have bad content. Do not rely on guardrails alone; combine them with narrowed permissions.

Sandboxes: a separate place to test

A sandbox is a testing environment cut off from production. Anthropic's guide notes that autonomous agents tend to cost more and can compound errors, and recommends extensive testing in sandboxed environments along with appropriate guardrails.

In n8n, you can group workflows and credentials into projects. If you separate a test project from a production project and put only test credentials in the test project, nothing touches production data while you test. In Dify, you can also test in a separate app or workspace.

Sandboxes are also used to run code written by AI. OWASP's “Agentic AI - Threats and Mitigations” recommends restricting execution permissions for AI-generated code and running it in a sandbox.

Deciding which actions need human approval

Requiring human approval for every action adds to the reviewer's workload. OWASP describes a tiered approach: actions that are reversible or low-impact pass automatically, while irreversible or high-impact actions go to a person for review. As an example, it cites processing a refund in store credit automatically because it can be reversed, while sending a transfer outside goes to human approval.

The AI Guidelines for Business (version 1.2), issued by Japan's government, ask organizations to consider bringing in human judgment at appropriate points rather than letting AI decide alone. They also call for measures so that human judgment is not swayed by excessive trust in machines (automation bias). Make approval requests state specifically what the AI is about to do.

Example permission settings in n8n and Dify

Permissions in n8n

Permissions in n8n work at two levels: instance-wide roles and per-project roles. Instance roles are Owner, Admin and Member. Projects group workflows and credentials and are assigned Admin, Editor or Viewer roles. Viewer is read-only and cannot even run workflows manually.

Available roles depend on your plan. Project roles are available on all n8n Cloud plans and on self-hosted Registered Community, Business and Enterprise. Editor is available on n8n Cloud Pro and self-hosted Enterprise, and Viewer on Enterprise.

You can add human approval to an AI agent's tools. If approved, the tool runs; if rejected, it does not. Approval requests can be sent to Slack, Microsoft Teams, Gmail and more. If you self-host, you can run a security audit with the n8n audit command. The audit report is divided into five areas: credentials, database, filesystem, nodes and instance.

Permissions in Dify

A Dify workspace has four roles. Owner manages the whole workspace, and there is one per workspace. Admin can manage members and model providers. Editor can create, edit and delete apps and knowledge. Normal can only use published apps. The member limit is 1 on Sandbox, 3 on Professional and 50 on Team.

Web apps built with Dify are public by default, and anyone with the URL can open them. If they are for internal use only, check who can access them. Workflows have a Human Input node that pauses to wait for a person's input and can request confirmation by email or other channels. Agents let you set an iteration limit (Maximum Iterations).

How an organization sets rules for AI use is covered in AI governance, and preparing for mistakes and runaway behavior in AI agent risks.

When adopting through Employee Store

On Employee Store, you can adopt AI agents built by developers with a one-time purchase or a monthly plan. Before adopting, check which account the AI agent runs under, which permissions it needs and which actions require human approval. After purchase, you can ask the seller through messages in the deal room. AI agents on offer can be found in AI employees.