You would never give a new hire the owner’s login on their first day. You would not hand them the company card with no limit, or the ability to delete customer records, or the authority to send an email to every client. Not because they are untrustworthy, but because nobody gets that on day one, and because mistakes happen.
Then a vendor installs an AI agent, connects it to your CRM, your inbox, and your accounting package with your credentials, and tells you it will “take care of things.” That is the day-one hire with the master key, and it is how most agent incidents start.
This article is about AI agent permissions: the practical, least-privilege setup that lets an agent be useful without being dangerous. Separate accounts, scoped keys, spending caps, allowed-action lists, approval gates, kill switches, and what to log. None of it is exotic. All of it is the difference between a tool and a liability.
What this actually is
An AI agent is a large language model (an LLM, the kind of AI that reads and writes text) that has been given tools: specific things it may do in your systems, like look up a customer, draft an email, create an invoice, or update a record. When the agent decides to use a tool, ordinary software carries out the action using whatever access that software was given. The agent’s permissions are simply the sum of what those tools are allowed to do and which accounts they do it as.
“Least privilege” is an old idea from computer security: every person and every program gets the minimum access needed for its job, and nothing more. It exists because access that is not needed cannot be misused, whether by mistake, by an attacker, or by a confused model. Applied to agents, it is the whole safety story in three words.
Why it matters more for agents than for people: a model can be talked into things. Text inside an email or a document it was asked to read can carry instructions, and the model may follow them (the attack is called prompt injection, explained in Prompt Injection Explained: AI Security for Your Business). An agent processing a thousand documents is exposed a thousand times. The permissions have to hold when the model does not.
The least-privilege setup, rule by rule
1. Give the agent its own accounts, never a person’s
The agent gets its own login in every system it touches: its own CRM user, its own email address, its own accounting user, its own database account. Never the owner’s, never a shared admin, never a staff member’s.
Three reasons. Its actions are then distinguishable from a person’s in every log. Its access can be cut in one place without locking out a human. And its permissions can be set to exactly what it needs, rather than inheriting everything the owner can do. This is the most common thing we find wrong when reviewing an agent someone else installed.
2. Scope every key to the narrowest access that does the job
An API key is a password-like credential that lets one program talk to another. Most systems can issue keys with limited scope: read-only, one folder, one mailbox, one type of record. Use those limits. An agent that answers questions about invoice status needs a read key for invoices, not a full-access key to the accounting package.
Keys should also expire and be rotated (replaced on a schedule), and they should live in a secrets store, not in a file a developer emailed around. Ask your vendor where the keys are and what each one can do. The same discipline applies to connections made through MCP, the tool standard described in MCP (Model Context Protocol) Explained for Business Owners: the tool list is the scope, so keep it short.
3. Separate reading from writing, and grant writes one at a time
Reads are low risk and should be generous, because the agent’s usefulness comes from what it can see. Writes are where damage happens and should be added deliberately, each on its own merits, with its own limits: “create a draft” before “send,” “propose a work order” before “create one,” “flag for refund” instead of “issue refund.”
The practical pattern is the trust ladder described in Building an AI Operations Agent for a Small Business: read only, then draft, then act with approval, then act alone for a narrow class of task. Each write permission is a rung, earned from evidence in the log, and each can be revoked independently.
4. Keep a written list of allowed actions, and enforce it outside the model
The agent should have an explicit list of what it may do, and that list should be enforced by the software around it, not by the model’s good behavior. If “send email to external address” is not on the list, the tool refuses, regardless of what the model asks for or why.
This is the distinction between an instruction and a wall. “Do not email customers without approval” in the agent’s instructions is a request that a manipulated model can ignore. A send tool that only accepts internal addresses is a wall. Both are good; only the wall is reliable. Destructive actions (delete, bulk update, close account, cancel order) should usually not exist as tools at all; the agent proposes them and a person with that power acts.
5. Put spending caps on everything that costs money
There are two kinds of spending an agent can do. The first is its own running cost: model usage, which can spike if the agent loops on a task or is fed an enormous document. Set a hard monthly cap at the model provider and a per-run limit in the code, so a bad day costs a bounded amount. Most providers offer usage limits in their settings; use them.
The second is real money: refunds, purchases, payments, credits. The safe default is that the agent cannot move money at all. If it must, the limits are a per-transaction cap, a daily cap, an allowed list of payees, and a person’s approval above a low threshold, all enforced by the payment tool rather than the model. An agent with an uncapped ability to spend is the incident that makes the trade press.
6. Require a human approval gate for anything irreversible
Some actions cannot be undone: an email sent, a payment made, a record deleted, a customer told something. For these, the agent proposes and a person disposes. The approval should be a fast, clear surface (a digest with approve and edit buttons, a Slack message, a queue in your tool) showing what the agent wants to do, the data it based that on, and a one-click yes.
Approval gates are also where you learn. The proposals a person rejects, and why, should feed back into the agent’s instructions. The wider set of guardrails for AI that talks to customers is in AI Hallucination Guardrails for Business Applications.
7. Build a kill switch and test it
There must be a single, obvious way to stop the agent entirely, usable by a non-technical person, that works in seconds. It should stop new runs, halt anything in progress, and revoke the agent’s ability to act until a person turns it back on.
Test it before the agent goes live and again periodically. A kill switch that has never been pulled is a hope, not a control. Pair it with alerts: if the agent errors repeatedly or tries an action that is not on the list, someone should hear about it within minutes.
8. Rate-limit the agent so a mistake stays small
Even permitted actions become dangerous at volume. An agent allowed to send confirmation emails should be allowed to send twenty an hour, not two thousand. An agent allowed to update records should have a cap per run. Rate limits turn a bad loop or a manipulated run from a disaster into a nuisance.
Set the limits at the tool, where they hold regardless of what the model does, and set them lower than you think you need. Raising a limit after a month of clean logs is easy.
9. Log everything, and make the log readable by an owner
Every run should record what triggered it, every tool call with its inputs and outputs, what the model decided and its stated reasoning, what a person approved or rejected, and what actually happened. The log is the audit trail for a regulator or an accountant, the evidence for granting or removing permissions, and the answer to “why did it do that.”
It also has to be readable by you, not just by a developer. In the systems we build, the log is the first thing added, and a plain-language view of it is part of the delivery. Where the log contains customer data, it is subject to the same rules as any other store of that data; see AI Data Privacy for Business, What Happens to Customer Data.
10. Review the permissions on a schedule
Permissions drift. A tool added for a one-off task stays enabled. A key issued for testing keeps working. A write that was earned for one category quietly applies to another. Put a monthly review in the calendar: what accounts does the agent hold, what can each key do, what is on the allowed-action list, what were the rejections this month, and does any of it still need to be there.
The review takes an hour and is the cheapest security work there is.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: an e-commerce retailer with 40 staff, running on a common storefront platform with a help desk, a shipping tool, and an accounting package. A vendor installed a customer service agent last year, connected to all four with the operations manager’s credentials, able to issue refunds of any amount, with no log beyond the chat transcripts. It worked well until a customer’s message contained a line that caused the agent to apply a discount code it should not have. Nobody noticed for a week.
A retailer like this, rebuilding the agent on least privilege, would end up with:
- A dedicated agent user in each of the four systems, with the operations manager’s credentials rotated and never used by software again.
- Read access to orders, shipments, customers, and tickets. Write access to exactly two things: post a draft reply to a ticket, and flag an order for refund review. No discount tool, no refund tool, no delete tool.
- Refunds and discounts handled by a person from a review queue the agent feeds, with the agent’s summary and the order data attached.
- Rate limits at the help desk tool: a cap on drafts per hour and a hard stop if the agent tries any action outside its list, with an alert to the manager.
- A kill switch on the operations dashboard, tested on go-live day, and a spending cap at the model provider.
- A log of every tool call, viewable by the manager, reviewed monthly alongside the permission list.
What changes: the agent is as useful as before for the routine questions, a refund takes a person ten seconds from the queue, and the manager can answer “what did the agent do last Tuesday” in one search.
What it costs to run
Least privilege costs almost nothing to run and a little to set up. Dedicated accounts in your existing systems are usually free or a single extra seat; check each vendor’s pricing page. A secrets store for keys is included in most hosting platforms. Rate limits, allowed-action lists, and the kill switch are code, built once.
The log is a small database on a server you likely already have, or a hosted one at $10 to $30 a month. Spending caps at the model provider cost nothing and can save a great deal. The real recurring cost is the hour a month for the review, and it is the best hour in the calendar.
The mistakes we see most
The owner’s login. The agent runs as a person. Its actions are indistinguishable, its access is total, and revoking it locks a human out.
Full-access keys “for now.” Testing keys with every permission that never get replaced. Scope them from the start.
Refund and delete tools. Irreversible actions exposed to the model because it was convenient. Take them out; let the agent propose.
Instructions instead of walls. “Do not do X” in the prompt, with nothing preventing X. A manipulated model does X.
No log, or a log nobody reads. The evidence for every permission decision, unread.
When to bring in help
If you are using a mainstream AI assistant connected to a vendor’s systems through their settings screens, you can apply most of this yourself: dedicated accounts, read-only where offered, the shortest tool list, and a habit of checking what is connected.
The moment an agent can write to your systems, touch money, or act without a click, the walls need to be built into software: scoped tools, enforced action lists, rate limits, spending caps, the approval surface, the kill switch, and the log. That is developer work, and a vendor who has not built it should not be handing you an agent that acts.
Levelbrook builds agents this way for businesses, with least privilege as the default rather than an upgrade, at a fixed price from a written scope, running in accounts you own. If you have an agent already and are not sure what it can do, the form below is how a review starts.