AI Agent Permissions: RBAC, MCP Access and Delegation

An AI agent should get permissions the way a new employee on probation does, only stricter. The agent gets a separate account with a role (RBAC), access only to the projects and actions it needs, human approval for anything hard to undo, and a complete log. Connecting through MCP doesn’t change these rules: the MCP server’s token should grant exactly as many permissions as the scenario requires.

This article is for IT leaders, team leads and information security specialists connecting AI agents to a task tracker, CRM or repository. We cover the permission model, an “action → risk → control” table, MCP, delegation, local models and a pre-launch checklist.

Why agent permissions are architecture, not a checkbox

While AI only answered questions in a chat, permissions were barely an issue. In 2026, agents work inside business systems: they create tasks, change statuses, write comments and update customer records. Plane now has AI agents inside the workspace and MCP connectors; Atlassian has Rovo and Jira Automation. The agent has become a participant in the process with access to data.

Agents have three properties that make a permissions mistake more costly than with a person:

• Speed. A person makes a mistake in one task; an agent repeats it across a hundred in a minute.
• Literalness. An agent follows an instruction even if it came from the text of a task or a customer email rather than from its owner.
• Invisibility. If an agent works under someone else’s account, its actions are indistinguishable from the person’s.

There’s also an organizational reason. The security team and lawyers will approve an agent faster if you show them a clear model: which role, which projects, which actions are prohibited, where the log is. Without such a model, the discussion boils down to a vague “AI is unsafe,” and the pilot gets postponed.

That’s why agent permissions are designed before launch. We covered automation levels in our article rules, scripts or AI agents; here we focus on access.

An agent is a user with a role

The basic principle: each agent has its own account or service account, and permissions are granted through a role. Not through an administrator’s personal token, and not through the account of an employee who “set it up and forgot about it.”

What this gives you:

• The agent’s actions show up in the log under its own name.
• Permissions change in one place, by changing the role.
• The agent can be disabled without affecting people.
• The security team sees agents in the shared list of users and roles.

Typical roles we start with:

Agent role	Can	Cannot	Example scenario
Reader	Read tasks, documents and comments in selected projects	Create or change anything	Project summaries, search, answering questions
Draft author	Create draft tasks and comments	Change statuses, assignees, due dates	Tasks from emails and meeting notes
Triager	Set labels, type and priority on incoming items	Close or delete tasks	Triage of Intake and bug reports
Executor with approval	Change fields and statuses after human approval	Change permissions, delete, message customers directly	Status updates after a review

An agent is never given the administrator role. If a scenario requires admin rights, that’s a sign the scenario needs to be split up.

Every agent should have a human owner. That person is responsible for the agent’s instructions, reviews the log and decides whether to expand permissions. It helps to name service accounts consistently, for example with an “agent-” prefix and the scenario name: that way they stand out in the user list, in filters and in reports. When a scenario is retired, the account is disabled rather than left hanging with an active token.

Least privilege: action, risk, control

For agents, the principle of least privilege reads like this: the agent gets permissions for one scenario, in one set of projects, for a limited pilot period. Expanding them is a separate decision based on the log.

Agent action	Risk	Control
Reading tasks and documents	Data leaking in responses or to an external model	Access only to the necessary projects, check where data goes
Creating a task	Noise and duplicates in the backlog	“Created by agent” label, daily cap on the number of tasks
Commenting on a task	Inaccurate information looks like the team’s position	Author marking, no mentions of customers
Changing status or assignee	Broken process, false picture of progress	Human approval
Bulk changes	Hundreds of corrupted tasks in a minute	Prohibited, or approval with a preview
Deletion	Data loss	Prohibited
Changing permissions and roles	Privilege escalation	Prohibited
Message to a customer	Reputational and legal risk	Draft only; a human sends it
Changing a deal in the CRM	Wrong amounts and forecasts	Approval by the deal owner

In Plane, granular permissions (Granular Access Control), LDAP and IdP groups are available on higher plans. In Jira, permissions are set through project permission schemes. In both cases, check which mechanisms your version and plan actually have before promising the security team a specific access model.

Human approval and the log

The approval point goes where an action is hard to undo or where it goes beyond the team. A handy rule: the agent proposes, the human approves. The agent prepares a change, shows exactly what will change and waits for approval from the process owner.

To keep approval from turning into a formality:

• The approver is the person responsible for the outcome, not just any team member.
• Before approving, you can see what will change: fields before and after, the list of tasks.
• Bulk operations are approved as a whole, not one task at a time.
• If there’s no approval within a set time, the action is canceled rather than executed.

What to record in the log

An agent’s action log answers five questions: which agent, on whose behalf, at whose request, what it changed, and who approved it. In practice, that’s a set of fields:

• the agent’s identifier and the version of its instructions;
• the initiator: a person, a rule or a schedule;
• the original request or event that triggered the agent;
• the list of tools called and objects affected;
• field values before and after the change;
• who approved the action and when, or why it was rejected.

Store the log where the rest of your audit data is stored, with the same retention period. During the pilot, review it weekly with the scenario owner: that’s the fastest way to see where the agent lacks permissions and where it has too many.

MCP: access to systems through a standard protocol

MCP (Model Context Protocol) is an open protocol through which an AI client connects to external systems. An MCP server describes a set of tools: “find tasks,” “create a task,” “update a field.” The model decides which tool to call. In 2026, Plane has MCP connectors, which are used to connect the tracker to AI assistants and development environments.

MCP’s convenience lies in standardization. The risk is that connections are often made with a broad token, and the agent gets everything that token can do. Rules for MCP:

1. A separate token for each connection. Not a shared administrator key.
2. A token from a service account with a role. The MCP server’s permissions are limited to that account’s permissions.
3. An allowlist of tools. If the scenario only needs read access, write tools aren’t connected.
4. Caution with third-party MCP servers. A server from a public catalog is code with access to your data. Check the source and run it inside your own environment.
5. Protection against instructions in data. The text of a task or email may contain instructions for the model. A read-only agent is barely vulnerable to this kind of attack; an agent with write access is dangerous.

Delegation: the agent acts on a person’s behalf

Sometimes an agent needs to act on behalf of a specific person: a developer asks the IDE assistant to close a task after a merge, or a manager asks it to draft a comment for a customer. That’s delegation, and it has its own rules.

• A delegated agent’s permissions are no broader than those of the person who launched it, and usually narrower.
• The log shows both the agent and the person: “agent X at the request of Y.”
• Delegation is limited in time and scope, not granted forever.
• The person can revoke delegation at any time, without needing an administrator.

If the system can’t distinguish between “a person” and “an agent acting on a person’s behalf,” use a separate service account. A clean log matters more than convenience.

Local models and keeping data in-house

Kazakhstan context. When an agent reads tasks and customer records and sends them to an external model, the data leaves your environment and often leaves Kazakhstan. The way the agent processes data should be approved by the security team. If it matters to the company that data doesn’t leave the country, there is an option with no external calls: Plane Airgapped runs entirely without internet and supports a local AI model. Jira Cloud stores data in Atlassian regions, and Kazakhstan isn’t among them.

If the model is external, reduce the amount of data that reaches it. An agent triaging bug reports doesn’t need customers’ phone numbers, and an agent summarizing a sprint doesn’t need attachments. Limit the projects and fields the agent can access, and don’t connect CRM objects containing personal data to an external model without approval.

A local model doesn’t replace RBAC. It removes the risk of sending data to a provider, but an agent with broad permissions inside your environment is still an agent with broad permissions.

Pre-launch checklist for an agent

1. The scenario is described in one sentence and has an owner.
2. A separate service account with a role for this scenario has been created.
3. Access is limited to the necessary projects or CRM objects.
4. Deletion, permission changes and bulk operations are prohibited or require approval.
5. The agent prepares messages to customers only as drafts.
6. A separate token has been issued for MCP, and only the necessary tools are connected.
7. It’s clear which model processes the data and where it runs.
8. The log records the agent, initiator, change and approval.
9. There’s a way to disable the agent within a minute without a developer.
10. A pilot review date and criteria for expanding permissions have been set.

How we do it

We start with a diagnostic: which scenarios you want to hand to agents, what data they touch, and what the security team will say. Then we run a pilot with one team and one agent in the “reader” or “draft author” role, review the log, and only after that expand permissions and bring in other teams. If data has to stay in Kazakhstan, we design an environment with a self-hosted tracker and a local model. We described the scenarios themselves in our article on AI agents in task management.

If you want to connect agents without unnecessary risk, see the business automation and AI assistant implementation page. It describes how the work starts and what’s included in the outcome.

---

Sources. Plane plans and features: plane.so/pricing. Plane repository: github.com/makeplane/plane. Atlassian Cloud data storage regions: Atlassian documentation. Data as of October 2026.

Terms in plain words

RBAC (Role-Based Access Control)

Access management through roles: permissions are granted to a role, not to a specific person or agent. To expand or cut an agent’s access, you just change its role.

MCP (Model Context Protocol)

An open standard through which an AI client connects to a tracker, CRM or code repository and calls their functions. It is risky if the connection uses a key with overly broad permissions.

Service account

An account for a program or agent rather than a person. Its actions show up separately in the log, and it can be disabled without affecting employees.

Token

A digital key an agent or MCP server uses to sign in to a system, gaining all of that key’s permissions. That’s why each connection gets its own narrowly scoped token.

Principle of least privilege

A security rule: grant only the permissions a scenario can’t work without. For an agent, that means one scenario, the necessary projects and a limited pilot period.

Privilege escalation

A situation where an agent or user ends up with more permissions than were granted. To rule it out, agents are forbidden from changing permissions and roles.

Delegation

A mode in which an agent acts on behalf of a specific person and gets no more permissions than that person has. The log shows both the agent and whoever launched it.

Local model

An AI model that runs inside the company’s environment without calling an external provider. It removes the question of sending data abroad but doesn’t remove the need to limit the agent’s permissions.