How Do You Give an AI Agent Only the Access It Needs?

How Do You Give an AI Agent Only the Access It Needs?

Scope the agent's tools to the task, scope each tool's credentials to the minimum permission, and make the system on the other side enforce the rules rather than trusting the model to behave. An agent should not be able to do damage it was never asked to do, even when something goes wrong.

We build AI automations for marketing and web teams, and this is the part clients skip. The demo works, the agent is useful, and nobody goes back to ask what else that API key can reach. Usually the answer is everything.

This is a practical walkthrough of how to lock an agent down without making it useless, using the standards that exist rather than inventing a policy from scratch.

What Is Excessive Agency and Why Does It Matter?

Excessive agency is when a system can take damaging actions because it was given more power than its job required. OWASP lists it as LLM06:2025 in its Top 10 for LLM Applications, describing the risk as damaging actions performed in response to unexpected, ambiguous or manipulated model output.

The phrase "manipulated output" is the important one. Prompt injection sits at the top of the same OWASP list as LLM01:2025, and the two problems compound. Injection is how an attacker gets the model to ask for something. Excessive agency is what determines whether that request does any harm.

This is why we treat permission design as the real control and prompt hardening as a helpful extra. You cannot write a system prompt strong enough to survive every input. You can write a token that simply cannot delete anything.

What Are the Three Ways an Agent Gets Too Much Power?

OWASP names three root causes, and they are usefully distinct. Excessive functionality means the agent can reach extensions and capabilities it does not need. Excessive permissions means those extensions run with broader access rights than the task requires. Excessive autonomy means high impact actions go ahead with no verification step.

Most teams fix one and think they are done. Trimming the tool list is easy and visible, so that is the one that gets done. The credentials behind the remaining tools usually stay exactly as broad as they were, because changing them means talking to whoever owns the database.

In our work, the permission layer is where the real risk lives. A single read and write key to a production system, handed to a tool that only ever reads, is the most common finding when we look at an automation somebody built in a hurry.

What Does Least Privilege Look Like in Practice?

It looks like a separate credential per job, created for that job, with the narrowest grant that makes the job work. Not the team key. Not the founder's personal token. A role that can do this one thing and nothing else.

Our own publishing automation is built this way. The account that writes blog posts can insert and update rows in the posts table and read the categories table. It cannot touch our case study data, it cannot delete anything, and it cannot change the schema. If that automation went badly wrong tomorrow, the worst case is some bad blog posts, which is a recoverable afternoon rather than an incident.

That shape generalises well. Ask what the worst thing this credential could do if the agent were fully compromised, and keep narrowing until the answer is something you could live through.

How Do Tool Protocols Handle This?

The Model Context Protocol builds it into the authorization flow. In the specification version dated 28 July 2026, an MCP server acts as an OAuth 2.1 resource server and the client acts as an OAuth 2.1 client, with a separate authorization server issuing the tokens. The server's job is to validate tokens, not to manage logins.

The spec is explicit about least privilege. It says clients should request only the scopes necessary for their intended operations, and that servers should return the required scopes in a WWW-Authenticate header so a client gets immediate guidance rather than asking for everything. The scopes_supported field is meant to represent the minimal set needed for basic functionality, with anything extra requested later through a step up flow.

We covered the wider picture of this protocol in our piece on MCP servers for web teams. The authorization design is the part that should reassure a security reviewer.

What Should Happen When an Agent Asks for Too Much?

It should be refused clearly and told what it would need. The MCP specification maps this to standard HTTP behaviour: an invalid or expired token must return 401, and a request whose token lacks the right scope should return 403 with an insufficient_scope error and a scope parameter naming the minimum scopes required for that operation.

The spec also warns against dribbling those requirements out one at a time. Servers are told to include every scope needed for the current operation in a single challenge, because challenging incrementally forces repeated authorization round trips for one operation and makes the experience worse.

We have had sessions where a connector exposed only its read-only tools and no write tools at all, and the automation simply could not perform the write it wanted. That is not a bug report. That is the control working, and the right response is to build a fallback path rather than to widen the token.

Where Should Authorization Actually Be Enforced?

In the downstream system, never in the prompt. OWASP's mitigation guidance for excessive agency says to enforce authorization in downstream systems and to run extensions in an individual user's context rather than with a generic high privilege identity.

This is the single most valuable line in the whole topic. If the database will refuse the delete, it does not matter what the model was persuaded to ask for. If the database will allow it and only your instructions say otherwise, you have a policy, not a control.

It also changes how you think about testing. You are not testing whether the agent behaves. You are testing whether the system refuses the agent when it misbehaves, which is a test you can actually write and run.

When Should a Human Approve an Action?

When the action is hard to reverse, visible to someone outside the company, or expensive. OWASP's mitigation list includes human approval for significant actions, and that maps neatly onto a rule we use: anything that publishes, pays, emails a customer or deletes gets a person in the loop.

Everything else should run unattended, because approval fatigue is real. An agent that asks permission forty times a day trains its reviewer to click yes without reading, which is worse than no approval step at all because it manufactures a false record of oversight.

We went deeper on where to place those checkpoints in our piece on human in the loop AI automation.

How Do You Prove It Worked?

Logs that record the tool call, the arguments, the identity used and the outcome. Monitoring does not prevent excessive agency, and OWASP says so directly, but it is how you find out what happened and how fast you can undo it.

The detail people forget is logging the identity. If every automation runs as the same service account, your logs tell you a thing happened but not which workflow caused it. Separate credentials per job give you separate lines in the log for free.

Our piece on logging and observability for AI agents covers what to capture and what to leave out.

Where Should a Team Start This Week?

Pick your most useful existing automation and write down, honestly, what its credentials can reach. Not what it uses. What it could reach. That list is usually longer than anyone expects, and it is the whole argument for doing this work.

Then narrow one credential. Create a role scoped to the actual task, swap it in, and confirm the automation still runs. Repeat until every agent in your stack has its own identity with its own limits. It is unglamorous work that takes a few afternoons and removes most of the scenarios that would otherwise keep you up at night.

If you want a second pair of eyes on an automation before it touches production data, we are happy to walk through it. You can reach our team at phoenix.studio.