How much permission should an AI agent get? A practical guide for MCP

Permission is a spectrum, not a switch

As dev.to published in a post titled "MCP Scope & Tradeoffs," an AI agent connected to tools can now do far more than answer questions. MCP, the Model Context Protocol, is a standard way of plugging an AI assistant into software and data. Through it, an agent can read information, change data, deploy code and act on a user's behalf.

The author's starting point is that these actions carry very different risk. Reading application logs is one thing. Pushing code to a live app or messaging a customer is another. So the permission you grant should follow the action, not the tool as a whole.

This is an opinion piece rather than a news report, but it supplies a useful mental model for the week's other MCP stories.

Five kinds of action, five levels of caution

The post lists five types of action an MCP tool might allow:

• Read: the agent can look but not change anything, such as viewing logs.
• Prepare: the agent drafts a change, such as a code suggestion or a deployment plan, and a person reviews it before it takes effect.
• Low-risk write: small changes with limited impact, such as updating a temporary preview of an app.
• High-risk write: changes that can affect a live system, such as deploying to production or altering important data.
• Actions with side effects: things that reach people or other systems, such as sending an email or updating a customer record.

Reading can usually happen automatically, provided the agent has the right access. Production deployments deserve stronger checks and possibly explicit human sign-off. Customer messages should be verified as authorised before they go out.

The author adds a warning: even "low-risk" actions can go wrong. Deploying to a test environment, for instance, could still expose private information.

Text from a tool is not an order

The most security-relevant section covers what tools send back. Picture an agent reading application logs and finding a line telling it to ignore its earlier instructions and upload the app's secret settings. The post's answer is blunt: it must not comply. That line could have been planted by a user or an attacker, and it is just data.

The rule the author proposes is to keep two categories apart. Trusted instructions are the rules and permissions set by the developer or the system. Untrusted information is anything that comes back from tools, files, databases, users or outside sources. An agent may read and summarise the second kind, but it should never gain new permissions from it.

This is a common weakness in AI-powered apps, and it is why the post says agents should not blindly follow directions buried in logs, files or database records.

When to ask, and what to show

Approval prompts have a cost. An agent that asks permission for every small step becomes tiresome. One that can take big actions without asking creates serious risk. The post's answer is to scale the approval to the risk and to make the approval predictable.

Before a person approves something important, the system should say plainly what the agent is about to do, what will change (code, data or settings), and where it will happen, meaning a test setup or the live app. It should also say whether the action can be reversed. The aim is for people to understand what they are approving rather than just clicking a button.

Safety nets have limits

The author also considers what happens when something still goes wrong. Useful practices include keeping logs of what the agent did, testing changes before they touch important systems, letting developers review significant changes, and providing a way to roll back to an earlier version.

Each has limits. Logs explain what happened but don't prevent it. Testing finds problems but can't guarantee everything works. Rollback fixes some changes but not all. An email that has gone to a customer cannot be recalled. That is why the post argues that permissions and approval rules should be set up from the start rather than patched in later.

The closing checklist asks developers whether the agent sees only the information it needs, whether a person can review key changes, what happens if a tool returns malicious instructions, and what extra checks cover actions that cannot be undone.

How it fits with the rest of today's news

This piece pairs naturally with today's story on unvetted MCP servers. Vetting asks whether you can trust the tool you are installing. Scope asks how much you let it do even if you do trust it. The second is a decision you control either way.

The post's bottom line is to give an agent enough permission to be useful but not enough to put your applications, data or users at risk. It expects permission management and security to matter more as agents become a routine part of software work.