An AI agent should get the narrowest access that still lets its workflow finish. Grant it per system and per action, and have the system itself enforce the limits rather than instructions in a prompt. In practice, that means starting with read-only access, keeping consequential actions behind a named human approver and widening access only after the workflow has shown that it works.
Most teams frame this as a question of trust: whether to trust the agent with the inbox, the CRM or the accounting file. Framed that way, there are only two answers, and both are bad. If you give the agent everything, you have created a fast, tireless account that can do damage in every system it touches. If you give it nothing, you have paid for an expensive note taker.
The security frameworks below point to a third answer.
Treat access as a design decision
OWASP names the failure directly. Its entry on LLM06:2025 Excessive Agency describes the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model output. It traces the root cause to three things: excessive functionality, excessive permissions and excessive autonomy.
None of the three depends on how good the model is. Each one is about what you gave it.
For a business owner, that makes the decision manageable. You do not need to predict model behavior to make a sound call. You need to decide what the agent can reach, what it can do there and which actions require a person. Those are ordinary operational decisions, and you already make versions of them when you onboard a new employee.
The underlying principle is an old one. NIST defines least privilege as designing the architecture so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function. An AI employee is an entity with a function, so the same rule applies.
Four access tiers, from least to most
Access debates often stall because "access to the CRM" gets treated as a single switch. In practice there are at least four distinct levels, and most workflows can finish at tier two or three.
| Tier | What the agent can do | Fits workflows like | What it still cannot do |
|---|---|---|---|
| 1. Metadata | Sees that a record exists and its surface fields: sender, subject, timestamps, labels, status, owner | Queue monitoring, routing, alerting on stalled items, counting | Read the contents |
| 2. Read content | Opens full records to classify, extract, compare, and summarize | Inbox triage, lead qualification, status collection, reconciliation checks | Change anything |
| 3. Draft and stage | Creates drafts, proposed records, and queued updates that a person releases | Follow-up drafting, data entry preparation, recurring report preparation | Send or commit on its own |
| 4. Write with approval | Completes the write after an explicit human approval of that specific action | CRM updates, ticket status changes, scheduling | Act without the approval step |
A fifth level, unattended write, lets the agent complete actions with no review at all. Leave that decision until you have evidence to base it on. A workflow that stops at tier two is the easiest place to start for exactly this reason, which is why a read-only morning calendar brief was one of the first jobs we automated for ourselves.
Your systems already have these tiers
The permission settings in your systems already follow this ladder. Google's Gmail API scopes are a useful example, because they are published and specific:
gmail.metadataviews message metadata such as labels and headers, but not the email body.gmail.readonlyviews messages and settings.gmail.composemanages drafts and sends email.mail.google.comreads, composes, sends, and permanently deletes all mail.
Google's own documentation says to request that last scope only if the application needs to immediately and permanently delete threads and messages, and notes that you can perform all other actions using less permissive scopes.
That note sums up this article. The narrow options already exist. Broad access usually gets requested because it is easier to build against, even when the job does not require it.
In a vendor conversation, asking whether the agent is secure tells you little. Ask which exact scopes it will request, and what breaks if you grant the next one down.
Start at the lowest tier that still finishes the job
When you scope a workflow, run this test.
- Write down the finished output first. "Handles the inbox" is too vague. A usable version reads like this: every new inquiry is labeled by type, assigned an owner and has a reply drafted for review by 9am.
- List every read the agent must perform to produce that output.
- List every write, and mark which ones a person could do in under ten seconds.
- Grant reads at the lowest tier that supplies the fields you actually named.
- Keep every write a person could do in ten seconds at tier three. Drafting is almost always enough for the first version of a workflow.
The ten-second threshold is arbitrary on purpose. It moves the conversation onto real effort instead of theoretical convenience. If clicking send is the only manual step left, the agent has taken over the work and a person still makes the decision.
If you have not chosen a workflow yet, our guide to AI agent use cases for business covers how to choose a role and score your first workflow.
Do not ask the model to enforce the rule
An instruction such as "never send an email without approval" lives in the prompt. This mistake tends to last longer than the others, because the setup appears to work. A prompt instruction is a request to the model, and nothing stops the model from acting against it. OWASP's mitigation for excessive agency is explicit: implement authorization in downstream systems rather than relying on an LLM to decide whether an action is allowed, and enforce complete mediation so every request is validated against security policy.
In practice, that means:
- The credential the agent uses does not carry any permission you do not want exercised. If the agent should never delete, its token cannot delete.
- Approval gates live in the workflow or the destination system, outside the agent's instructions.
- The agent has its own identity, so its actions are attributable and revocable without disturbing a person's account.
OWASP's related guidance, to execute extensions in the user's context with the minimum scope necessary, points the same way. The boundary belongs in the systems and credentials themselves.
Reading is not risk free
It is easy to assume that read-only access is harmless. It is safer than write access, but it still carries risk.
An agent that reads your inbox is reading text that strangers wrote. OWASP's entry on LLM01:2025 Prompt Injection covers this as indirect prompt injection: input from external sources such as websites or files can alter the model's behavior in unintended ways, and the impact depends largely on the business context the model operates in and the agency it has been given.
OWASP's worked example is a mail assistant whose extension can both read and send. A crafted incoming email tricks it into scanning the mailbox for sensitive information and forwarding it to the attacker. Reading the email let the attack in, and the send permission is what did the damage.
This is why the tier matters more than trust. A tier two agent that reads a hostile email produces a bad summary. An agent with unattended write access that reads the same email can act on it. If you are setting up a free agent such as OpenClaw yourself, its own security record and the questions to settle first cover the same ground from the product side.
Keep these behind a person at launch
Whatever tier you choose, these actions should require a named human approver from the first day:
- Sending external communications to customers, prospects, or vendors
- Moving money, approving invoices, or changing payment details
- Creating or changing accounts, permissions, or access
- Deleting records, files, or history
- Anything that commits the business contractually
- Anything touching employment, legal rights, safety, or personal health and finances
- Changing the agent's own configuration, permissions, or approval rules
The last item is the one most often missed. If an agent can widen its own access, it has no real access boundary.
A per-system access worksheet
Fill this in once for each system, before anything is connected. It has seven fields.
- System and identity: the system, and the exact account the agent will use. A shared login does not qualify.
- Tier requested: one of the four above, in writing.
- Scope boundary: the specific mailbox, folder, pipeline, board or table. "The CRM" is too broad.
- Output produced: what the agent creates from this access. If you cannot name it, the access is not justified yet.
- Workflow owner: the person who reviews exceptions and decides whether the workflow is helping.
- Approval gates: which actions need a human yes, and who gives it.
- Revocation: how access is removed, who can remove it today and how long that takes.
Field seven is the one people skip until they need it. Test revocation before launch so you are not working it out during an incident.
Access should change after launch, in both directions
Treat the first grant as a hypothesis. Widen access only against evidence: the workflow has run long enough to show its exception rate, the owner has reviewed the output, and the next tier removes a real bottleneck rather than a theoretical one. Narrow it whenever a permission goes unused for a full review cycle, because an unused permission carries risk and does nothing for you.
Removing access later means someone has to notice, schedule the change and confirm nothing depends on it. That work competes with everything else on the list, which is the practical argument for starting narrow. Widening access later is a short change with a clear reason attached.
The NIST AI Risk Management Framework treats measurement and management as ongoing activities rather than a launch checklist, and access review belongs in that loop. For most small businesses, a quarterly pass over the worksheet is enough: what is connected, at what tier, producing what and reviewed by whom. OWASP's Top 10 for Agentic Applications is the reference to give a technical partner when you want the longer list of risks behind that review.
What this looks like in a managed AI employee
VantaSoft does this work before an agent runs, not after it misbehaves.
Each AI employee gets a defined job, approved systems, scoped permissions, explicit human approval points and escalation rules. Those decisions are recorded in the Order Form instead of being left to whoever configures the integration. Agents run in a customer-specific managed environment. Where read-only access is enough for the job, we use it: our QuickBooks Online integration is scoped to a single customer deployment, and the customer reviews the requested permissions before approving access.
No configuration removes risk entirely. What a boundary does is make the limit explicit, reviewable and revocable, so it works as a control rather than a promise.
Our own agents follow the same rules. The approval gates across our agent fleet list the actions none of them can take alone, starting with sending an email.
Frequently asked questions
Should an AI agent have its own login, or use an employee's account?
It should have its own. A separate identity makes every action attributable, lets you scope permissions to the workflow instead of to a person's entire job, and lets you revoke access without locking out a colleague.
Is read-only access safe?
It is safer, but not safe. Read-only access removes the ability to act, which is where most of the damage happens. It does not limit exposure of whatever the agent can read, and it does not stop hostile content from influencing the agent's output, so scope what the agent reads as well.
Can you grant broad access now and tighten it later?
You can, but the tightening rarely gets scheduled, and by the time anyone looks, something may depend on the extra permission. Starting narrow costs one conversation, and widening later is a short change with a documented reason.
What if a vendor cannot say exactly what access it needs?
The answer tells you more about the scoping than about security. Once a workflow is defined, you can derive the access list from it, so vagueness here usually means the workflow has not been specified yet.
Is this much process worth it for a small business?
Seven fields per system is about an hour of work. A smaller team has fewer people in a position to catch a bad action before it reaches a customer, which argues for tighter defaults rather than looser ones.
Decide the boundary before you connect the system
Getting real work out of an AI employee depends less on how much you trust it than on deciding, per system and per action, what it can see, what it can do and who signs off. The question that comes before it, whether each system can be connected at all, has its own scorecard in AI agent integration: which of your systems are ready to connect.
If you want help drawing those lines around a specific workflow, a discovery session is where to do it. It starts with 30 minutes on your workflows. Start Automating.
