AI Security

AI Agent Tool Permissions Need Least Privilege

globaltech

An AI agent should only be able to do what its task requires, nothing more. That is least privilege, and it matters more for agents than it ever did for people, because an agent acts on text it reads from the open internet, from documents, from other users. If that text can trick the agent, the only thing standing between a bad prompt and a bad outcome is the list of things the agent is allowed to do.

The OWASP Top 10 for LLM Applications lists excessive agency as a core risk in production AI systems, right alongside prompt injection. The two compound each other. Prompt injection gives an attacker a way to talk to the agent. Excessive permissions give the attacker something worth talking to. Fix either one and you cut the risk. Fix both and you close it.

On this page

Why agents need narrower permissions than the people who built them

A developer building an AI agent usually has broad access already: the database, the payment API, code deploys. That is fine for a person trusted to use judgment. An agent has no judgment. It follows whatever instructions look convincing, including ones hidden in a web page, an email, or a file it was asked to summarize.

Granting an agent the same access as its developer saves an afternoon of setup and creates a risk that never goes away. The agent runs thousands of times, on inputs the developer never saw, long after the project is finished.

  • Human trust is earned through judgment and accountability; agent trust must be earned through a narrow, tested scope.
  • Setup convenience is not a reason to grant an agent standing access.
  • Permissions granted for testing should never carry over unchanged into production.

Mapping what an agent can actually call

You cannot scope down what you have not counted. List every tool, API, plugin, and function the agent can invoke, and what each one can read, write, or delete. The list grows quietly as tools get bolted on.

This map is not a one-time exercise. New tools change the risk picture, so it should live next to the agent’s code, reviewed the way you review a dependency list.

  • List every function or API the agent can call, including ones added for a demo that shipped and was forgotten.
  • Record what each tool can read, write, or delete, not just what it was meant for.
  • Flag any tool that touches money, personal data, or infrastructure for extra review.

Scoping credentials per task, not per service

The common pattern is one service account per agent, with enough permissions to cover anything it might do. This is the opposite of least privilege. A support agent that occasionally issues a refund should not hold a credential that can issue any refund, to any account.

Scope credentials to the task in front of the agent, not the role it plays in general. A refund task gets a short-lived credential capped at a specific amount and order. Once the task ends, the credential expires. It costs more setup than one broad account, but it is the difference between a mistake that costs one order and one that costs the ledger.

  • Issue short-lived, task-scoped credentials instead of one standing account per agent.
  • Cap what a single task can spend, delete, or change, with hard limits the agent cannot override.
  • Expire credentials when the task completes, so old sessions cannot be replayed later.

The blast radius argument

Assume, for a moment, that a prompt injection will eventually succeed against your agent. This is not pessimism, it is the working assumption most serious AI security guides recommend, including MITRE ATLAS, which catalogs adversarial techniques against machine learning systems. Once an attacker gets a message through, the only question left is what it can make the agent do.

That is the blast radius. If the agent can only read a customer’s own order history, a successful injection can only leak that history. If it can also delete records, send emails as the company, or move funds, the same injection can do all of that too. Least privilege does not stop the injection. It stops it from mattering.

  • Design permissions assuming an attacker will eventually control the agent’s next action.
  • Separate read access from write access, and write access from anything irreversible.
  • Keep the worst-case outcome of a compromised agent small enough to be a non-event.

Operating rule: if you cannot describe, in one sentence, what the worst thing is that an agent could do with its current permissions, it has too many permissions.

Reviewing and revoking unused tool grants

Permissions accumulate and almost never shrink on their own. A tool gets added for a demo, the demo ships, and it stays wired in because removing it means retesting something nobody wants to touch. Across a year of feature work, an agent ends up holding access nobody can fully account for.

Set a fixed schedule to check the tool map against actual usage. Any tool the agent has not called in the review period is a candidate for removal. It is the discipline that keeps human access clean, applied to a system that runs far more often than any employee logs in.

  • Log every tool call the agent makes, including the ones it never uses.
  • Revoke access to tools that show no legitimate use over a review window.
  • Treat an unused grant as a liability, not a convenience.

Testing agents with adversarial input and broad tools

Before an agent goes live, feed it the input an attacker would try: instructions hidden in a document it must summarize, a fake system message in a web page, a request that sounds like it comes from an administrator. Then watch what it does with its tools.

This testing works best paired with the tool map. Run the same adversarial prompts against the agent with its full tool set, then again with a trimmed set, and compare the outcomes. The gap shows how much of your exposure comes from permissions rather than model behavior. Microsoft’s AI red teaming guidance treats this kind of testing as standard practice, not an optional extra.

  • Test with prompts designed to override instructions, not just prompts that check normal behavior.
  • Compare what the agent can do with full tool access versus a trimmed, task-scoped set.
  • Treat any successful adversarial run as a permissions bug, not only a prompting bug.

Treating agent permissions as a security control

Most companies already run a review cadence for human access: quarterly checks on admin rights, offboarding steps, approval chains for sensitive actions. Agent permissions deserve the same seriousness and usually get less, because an agent does not appear in the HR system and nobody owns the review.

Put agent tool grants on the same calendar as human IAM roles. Assign an owner who signs off on each agent’s permission list. When the agent’s task changes, its permissions change with it, reviewed and approved, not just expanded by whoever last touched the code.

  • Assign a named owner responsible for each agent’s permission list.
  • Review agent grants on the same schedule and rigor as human access reviews.
  • Require sign-off before an agent’s tool access is expanded.
Practice Broad standing access Least privilege for agents
Credential scope One service account for everything the agent might do Short-lived credential scoped to the current task
Impact of a successful prompt injection Can trigger any action the agent is capable of Limited to the narrow action the task required
Review cadence Rarely reviewed after initial setup Reviewed on the same schedule as human IAM roles
Unused tool grants Left in place indefinitely Logged, flagged, and revoked on a set schedule

FAQ

What does least privilege mean for an AI agent?

It means the agent can only call the specific tools and access the specific data its task requires, nothing broader, and that access expires once the task is done.

Why is excessive agency considered a top AI security risk?

Because an agent that can be manipulated through its input, and also holds broad permissions, gives an attacker a direct path from prompt to real-world action. The OWASP Top 10 for LLM Applications lists this as a core risk for exactly this reason.

Should an agent share credentials with the developer who built it?

No. Developer credentials reflect the trust placed in a person with judgment and accountability. An agent has neither, and should run on its own scoped, short-lived credentials instead.

How often should agent tool permissions be reviewed?

On the same cadence used for human access reviews, at minimum quarterly, with an additional check whenever the agent’s task or tool set changes.

What is the blast radius of an AI agent?

It is the full set of actions an attacker could trigger if they successfully manipulated the agent through its input. Narrower permissions mean a smaller blast radius, regardless of how good the underlying model is.

Who should own an agent’s permission list?

A named person, the same way a manager owns sign-off on a report’s access. Without an owner, permissions grow and never shrink.

Related reading

Conclusion

Least privilege is the difference between an AI agent mistake and an AI agent incident. Agents will be manipulated eventually, through documents, web pages, or messages crafted to look legitimate. The only variable you control after that is what the agent was allowed to do. Map its tools, scope its credentials to the task, review its grants on a fixed schedule, and test it against adversarial input before it goes near production.

For teams building AI capability alongside security work, external specialists can accelerate the program. See AI implementation services for implementation support.

Sources

Previous post Prompt Injection Defense Needs Layered Controls
Next post Model Supply Chain Needs Provenance Checks

More Stories