How Much Access Should You Give an AI Agent?

Give an AI agent the narrowest set of named actions the job needs, and never a raw credential. Most security advice on this question is written for enterprise identity teams and talks about short-lived tokens and identity governance, which is useless if you just pasted a database password into an AI node and called it done. The operator version is simpler and sharper: a workflow uses a credential on a path you drew, but an agent decides what to do with that credential at runtime. So the moment you hand an agent your database password or a full-scope API key, you have not given it one task, you have given it every action that key can perform, and you cannot list those actions in advance. The fix is to give the agent capabilities, small parameterized actions that each do one thing, and keep the credentials behind them where the agent never touches them.

This is the first agentic risk that became a published standard in 2026. On December 9, 2025, the OWASP GenAI Security Project released its Top 10 for Agentic Applications, and ASI03, Identity and Privilege Abuse, sits in the top three, defined plainly as the case where "leaked credentials let them operate far beyond their intended scope." ASI02, Tool Misuse, sits right above it. The standard exists because over-scoped agents are the default mistake, not a corner case.

Why the workflow rule of thumb breaks for agents

For years the safe habit was to give a workflow the credential it needs and move on. That habit is fine for a workflow, and it is exactly wrong for an agent, because the two systems use a credential in opposite ways.

A workflow runs a path you drew. If a step uses a Stripe key to issue a refund, that step issues a refund and only a refund, because you wired it to do that one thing in that one spot. The key sits on a fixed rail. The worst it can do is the operation you placed there, on the records that reach it.

An agent runs a path it picks. You hand it a set of tools and a goal, and the model chooses which tool to call, with what inputs, in what order, looping until it decides it is done. That is the whole point of an agent, and it is the same property that makes its access dangerous. If one of those tools is a generic "run a SQL query" tool wired to your database, the agent is not limited to the query you imagined. It can write any query the credential allows, including the ones you never want it to run. The reason you cannot just trust it to behave is the same reason an agent cannot be cleanly unit-tested: the set of actions it will take is not knowable before it runs. We walked through that property in detail in AI agent vs workflow, and it is the hinge of this whole question. If the path were knowable, you would build a workflow and this problem would not exist.

There is a second reason scoping matters even when your own prompt is careful. A successful prompt injection rewrites the agent's intent in the middle of a run, and at that moment every credential and tool you granted is working for the attacker instead of you. We covered the mechanics in prompt injection in AI automations. The defense that survives injection is not a better prompt, it is a smaller grant. If the agent can only call three narrow actions, a hijacked agent can only do three narrow things.

What you handed it versus what it can actually do

Operators tend to think in terms of what they meant the agent to do. The agent operates in terms of what it can do. Here is the gap, for the access patterns we see most often.

What you hand the agent	What it can actually do with it	Can you list those actions in advance?	Blast radius if hijacked or confused
Raw database credentials (read and write)	Any query it can compose, including UPDATE and DELETE across every table the role can reach	No	The whole database
Admin or full-scope API key	Every endpoint that key unlocks, not the one you had in mind	No	The whole account
Generic HTTP tool plus a stored credential	Any request to that host: any method, any path, any body	No	The entire API surface behind that credential
Read-only role on a replica or a scoped view	Reads only, limited to the rows and columns in the view	Partly: reads are bounded, the exact queries are not	Exposure of scoped data, not damage
One parameterized action (a sub-workflow tool)	Exactly the operation you defined, with the inputs you allow	Yes	One record, one operation

The pattern is clear reading down the right two columns. The grants you cannot enumerate are the grants with the largest blast radius, and they are the same grants people reach for first because they are the fastest to wire up. The bottom two rows cost more to set up and they are the only ones where you can say, before the agent runs, what the worst case is.

Give it capabilities, not credentials

The reframe that fixes this is to stop handing the agent keys and start handing it capabilities. A capability is one named action you defined, with the credential hidden inside it and the inputs constrained to what you allow. The agent calls look-up-order or issue-refund-up-to-100, and the key that actually talks to Stripe or Postgres lives inside that action, out of the model's reach. This is not a custom idea. It is what OWASP recommends as the core mitigation for LLM06:2025 Excessive Agency: avoid open-ended tools, and replace a broad capability like "run a shell command" with granular, single-purpose alternatives. The same document tells you to enforce authorization in the downstream system, not in the LLM, because asking the model to police its own access is asking the part you cannot test to be the part you trust most.

Three rules make this concrete.

Read by default, and read from a narrow surface. If the agent needs to know things, give it a read-only role against a replica or a view that contains only the rows and columns it should ever see. A support agent does not need the payments table. Scoping the read surface means a leak is an exposure of bounded data, not a path to everything.

Writes only as named actions on an allowlist. Never give an agent a generic write tool. Expose the specific operations the job needs, create-ticket, update-status, add-note, each as its own action with validated inputs. The agent can call them in any order it likes, which is fine, because each one does a single bounded thing and nothing else exists for it to call.

Irreversible actions behind a human gate. Sending money, emailing a customer, deleting a record, and posting to a partner system have no undo button. Those are the actions to route through approval before they fire, which is the same blast-radius logic we laid out in when an automation should require human approval. OWASP lists human approval for high-impact actions as a named control for exactly this reason.

How this looks in n8n, Zapier, and Make

The capability-versus-credential split is visible right in the no-code builders, because the tools you attach to an agent node are where the decision gets made.

In n8n, an AI Agent node does nothing until you connect tool sub-nodes to it. The HTTP Request Tool is the broad, dangerous option: it lets the agent compose its own requests to a host, so with a stored credential behind it the agent can hit any path and method that credential allows. The Call n8n Workflow Tool is the constrained option: it lets the agent run a sub-workflow you built, with the inputs you defined, and nothing else. The difference between those two tool nodes is the whole article. Wire the agent to the HTTP tool and you have handed it the API surface. Wire it to three named sub-workflows and you have handed it three actions. n8n stores credentials centrally and references them from nodes, so the key can sit inside the sub-workflow where the agent calls the workflow but never sees the credential.

Zapier and Make follow the same shape. The lesson is identical across all three: the safe build is a short list of specific actions, each doing one thing, never a general-purpose tool pointed at a credential. If you find yourself attaching a raw HTTP or SQL tool to an agent so it can "figure out the call it needs," that is the moment to stop and build the call as a named action instead. Designing and locking down those action layers is most of what we do when we build agent and assistant systems: the model gets to decide what to do, and the system decides what is even possible.

The five-minute access review before you ship

Before an agent goes live, run one pass over its tools. For each tool, ask a single question: what is the worst single call the agent could make with this, and can I undo it? If the answer is "any query against the database" or "any request to the account," the tool is too broad, and you replace it with the specific actions the job actually needs. If the answer is "create one ticket" or "read one order," you are in good shape.

Then check three things. Is every read scoped to a replica or a view rather than the live primary with a full role. Is every write a named action with validated inputs rather than a generic write tool. Is every irreversible action behind an approval step rather than firing on the model's say-so. An agent that passes those three is one where you can state the blast radius out loud before it ever runs, which is the only honest definition of "enough access."

Most agents we review fail this on the first tool, and the fix is never to make the model more careful. It is to take the keys out of its hands and give it actions instead. If you are wiring up an agent and are not sure where its access is too wide, tell us what it needs to do and we will help you draw the line between what it should decide and what it should never be able to reach.