Least Privilege for AI Agents: Scope the Tools and the Tokens

An agent should get the narrowest tools and the shortest-lived tokens that let it do the one job in front of it. The same goes for data: only the slice that job needs. Most agent security incidents I've looked at came down to an agent holding an admin key it never needed, so an ordinary mistake turned into a data leak. Prompt injection makes the headlines, but sloppy scoping causes most of the damage I've seen.

Why do agents end up with god-mode credentials?

Convenience, and the pilot. The developer building the demo used their own token or an existing service account, and it had access to everything because that's what made the demo work on Friday. The demo became the product, and "we'll tighten permissions later" turned into a ticket that lost to features every sprint.

This is the same dynamic that produces the security bill that comes due after vibe coding: speed borrowed against a bill nobody scheduled.

Scope the tools

Scoping tools means one tool per action, each with the smallest surface that action needs. No generic "run SQL." Reads and writes split into separate tools with separate permissions. Arguments validated in your own code before execution. Minimal fields returned. The model chooses the tool; your code decides whether the parameters are acceptable.

• Expose get_order(order_id) and list_orders(customer_id, limit) rather than a query endpoint.
• Split reads from writes, so a read-only agent literally cannot call a write.
• Allow-list tables and hosts, and enforce strict id formats, before anything runs.
• If the agent needs an order status, don't hand it the whole customer record.
• Give write tools a dry-run mode, and use it in evals and shadow phases.

Scope the tokens

Each agent gets its own service identity, and each task gets a token minted for that task. A support agent reading one customer's orders gets a token bound to that tenant, scoped to orders:read, with a ten-minute lifetime. If the agent is tricked, the blast radius is one customer's read-only order history for ten minutes.

Secrets never go into the prompt or the context window. The model shouldn't be able to see a key, so it can't be talked into repeating one. Every tool call is logged with the agent id, so the audit trail reads like a person's, because it should.

Scope the data

Retrieval has to respect the same access rules as the human asking. If your RAG index was built by a crawler running as an admin, the agent will happily surface documents the user could never open, and it will do it with a citation attached, which makes the leak look authoritative.

We caught exactly this in an internal pilot. A knowledge-base bot indexed a shared drive using a service account with broad read access, which included folders belonging to HR. During testing a colleague asked it, out of curiosity, what a particular role was paid, and it answered with a figure and a filename. It never left the pilot group, and it changed how we build every index since: document-level ACLs stored alongside the embeddings, filtered at query time by the caller's identity, with a re-sync whenever source permissions change. Row-level security in the vector store is mandatory if the source had it.

The checklist we run before an agent touches production

The review takes about an hour and covers tools, tokens, and the data behind retrieval. Nothing on it is exotic. It's a list of questions with named answers, and the value comes from writing those answers down somewhere a person outside the build team can read them.

1. For each tool: its narrowest scope, whether it reads or writes, what validates the arguments, and what a dry run looks like.
2. For each token: who mints it, what it's bound to, how long it lives, and where the call is logged.
3. For the data: whose permissions retrieval inherits, and how we know those permissions are current.

It's the best hour in the whole build. At Shanti Infosoft this review is a hard gate; the agent doesn't get a production identity until someone outside the build team has signed it off. It runs on every agent we deliver through our AI development work, including the ones a client will operate themselves afterwards.

If your agent were tricked into doing the worst thing its current permissions allow, what exactly would happen?

Sagar Jain is the technical co-founder of Shanti Infosoft, where agent systems ship under the same CMMI Level 5 process as everything else the team delivers.