AI Agent Permissions: A Least Privilege Playbook

AI agent permissions are the rules that decide what an agent can read, change and spend when it acts for someone. You will meet them the week your team asks to point an agent at production, and the meeting tends to go like this.

Picture it. An engineer has spent a few weeks with an agent in staging. It reads tickets, queries the database, drafts a fix and explains its reasoning. The demo lands well. Then comes the ask: can we run it in production, using the service account the team already has? Someone says, "It's mostly read access." Nobody says anything for a moment. The word "mostly" is now sitting on the table, and you are the one who has to decide whether to pick it up.

I want to give you something to say in that moment. First, why "mostly" is the problem.

Why an agent with your access is a different risk

A script does what its author wrote. An agent does what a model decides, in response to whatever text reaches it. That difference is the whole story.

OWASP names the failure in its GenAI Security Project. Under LLM06:2025 Excessive Agency, it describes damaging actions taken in response to unexpected, ambiguous or manipulated model output, whatever caused the model to misbehave. OWASP lists the root cause as one or more of excessive functionality, excessive permissions and excessive autonomy. Its own example of excessive permissions is an extension meant to read data that connects to a database with an identity holding SELECT, UPDATE, INSERT and DELETE rights.

Read that example again and then look at your service account. That is the meeting.

The risk gets sharper when the agent borrows a person's access. Snowflake states the concern directly in its engineering post on controlling agents in sessions: an agent that inherits a user's role could drop a production table or grant itself privileges. And in its announcement of CoCo and CoWork Bots, Snowflake says those bots inherit the user's access rights, role context and permissions and work in the background. That last part matters. The human is not watching each step. The permissions are.

So the question is not whether your agent is smart enough to avoid a bad action. The question is what the worst action is that its credentials allow.

What vendors shipped, and why the agreement matters

In the last days of October and the first of November 2026, several vendors announced controls that cap what an agent can do, and Datawiza describes a gateway with the same purpose. They are built differently, and they mostly agree.

Sources: Snowflake, SAP, Island, OmniTrust, Datawiza, Conduktor. These are vendor descriptions of their own products, not independent tests, and I am not ranking them.

The platforms differ. The shape of the answer does not. Give the agent less than the person has, make writes the exception, put a human in front of the costly actions, and keep a record of who did what. Whether you buy any of these products is a separate decision. The pattern is free, and you can apply it with the tools you already run.

The five layers I would put in front of an agent

What follows is my own judgment, not a standard. It is how I would organize the conversation in that meeting.

Identity: one agent, one name

Give each agent its own identity. Not a shared human login, and not the team's all-purpose service account. If two agents share one credential, you cannot tell them apart in a log, and you cannot revoke one without breaking the other.

Vendors are not unanimous here, and the difference is worth noticing. OmniTrust says each agent running on Halo has its own identity and permissions, separate from the person who created it. Conduktor says each of its agents operates with its own identity. Island takes a different route: it says agents inherit the user's enterprise identity, then applies a separate agent policy on top, which can target the user, the user and their agents together, or the agents alone. Either way, the agent ends up with something that policy can address. A bare inherited login does not give you that.

Scope: a ceiling below the person

Whatever the human can do is the wrong upper limit. Snowflake's design is the clearest statement of the right one: the ceiling can only restrict, never expand, what the user can do. I would copy that rule even where no product enforces it for you. Write down what the agent's task needs, grant that, and stop.

OWASP's list of root causes helps here. Strip out functions the task does not need, such as the delete tool that came bundled with the read tool. Then narrow the permissions on what remains.

Mode: read-only until proven otherwise

Conduktor says every agent starts in read-only mode and cannot make changes without human approval unless a team chooses to automate a given task. Island describes read-only mode for systems of record. I agree with the instinct. Read-only is how an agent earns trust: you watch it be right, repeatedly, on things that cannot hurt you, and you promote it one capability at a time.

Approval: a person signs off on what cannot be undone

Some actions deserve a human before they run. Deleting data, changing permissions, sending an external message, moving money, changing a production system. OmniTrust says its platform can require human approval for selected higher-impact actions and records the decisions.

I also write the opposite rule down. Approval fatigue is real. If a person clicks "yes" on every prompt without reading it, the control is decoration. Reserve approvals for the actions that justify the interruption, and make the approval screen show exactly what will change.

Evidence: a log that tells human from agent

When something goes wrong at 2am you need to answer one question quickly: did a person do this, or did the agent? Island says its audit logs record whether a human or an agent took the action. Datawiza's analysis describes audit trails that capture the initiating identity, the acting agent, the policy decision and the outcome. OmniTrust describes budgets at organization, user and agent level that can alert or pause an agent. Spending is a permission too. An agent that loops on a paid API is a permissions failure that shows up on an invoice.

Where to enforce it

Layers are only useful if something enforces them. You have four places to put the control, and they are not exclusive.

In the platform. Snowflake's scopes live in the data layer, so the limit holds regardless of which agent or tool connects. This is the strongest position, when your platform offers it.

At a gateway. SAP and Datawiza both describe a checkpoint between agents and the systems they call, over MCP and agent-to-agent connections. A gateway is useful when you have many tools and want one place to see the policy. If you are still working out what MCP does, I wrote a practical guide to the Model Context Protocol. Be careful not to treat a gateway as a substitute for narrow credentials downstream. It is a second lock, not the first.

In the browser. Island's approach puts the limits where an agent acts through a web interface. It also describes a built-in vault that injects credentials into login forms, so passwords never pass through the model's context window. That detail is worth stealing as a principle: the model should not hold the secret at all. A similar boundary is arriving on the open web. In my piece on WebMCP and AI agents on your website, the agent can call only the tools a site registers, and it can place an order only after the buyer confirms.

In your own workflows. If your agents run inside a workflow tool rather than a vendor suite, the controls are yours to build. That is also where they are easiest to skip.

Applying it in an n8n agent workflow

If you build agents in n8n, the same five layers apply, and none of this depends on a feature I would have to invent. These are my recommendations.

Create a dedicated credential for each agent workflow, scoped to what that workflow needs. Do not hand the agent's tools an admin-level API key because it was the one lying around. For every tool the agent can call, ask whether it reads or writes, and keep the writing tools out of the first version. Put an explicit approval step in front of any write action. Keep each workflow to one job, so its permissions can stay narrow. I made the same case about bots in giving each bot one owned outcome: a helper that owns everything needs access to everything.

Check the n8n documentation for the exact credential and approval options in the version you run. They change between releases.

Who should own this decision

Permissions do not get written well from a conference room. They get written by someone who can see which credentials exist, who created them and what they can reach. That is much of the argument for the forward deployed engineer, an engineer embedded close enough to the customer's environment to know the real answers. Whoever on your team plays that role should be in the permissions review.

One caution about what I do not know. I have no adoption figures or incident counts for agent misuse that I can stand behind, so I have not quoted any. If a vendor or analyst hands you a number, ask for the source and the date.

Back in the meeting

The engineer asked whether the agent can use the existing service account. My answer would be no, with a yes attached to something smaller.

Create a new identity for the agent. Give it read-only access to the two systems the task touches. Put approval in front of the one write the task needs. Turn on the log that separates agent from human. Run it for a while and read what it did.

Then, when the next person says "mostly," you will have a question to ask back: mostly what, and who can see it?