An AI agent should get the narrowest access that still lets its workflow finish, granted per system and per action, and enforced by the system itself rather than by instructions in a prompt. In practice that means starting read only, keeping consequential actions behind a named human approver, and widening access only after the workflow has proven it works.
Most teams frame this as a trust question. Do you trust it with the inbox? The CRM? The accounting file? Framed that way there are only two answers, and both are bad. Give the agent everything and you have created a fast, tireless account that can do damage in every system it touches. Give it nothing and you have bought an expensive note taker.
There is a third answer, and it is the one every serious security framework points to.
Access is a design decision, not a trust 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, and it places the root cause in three places: excessive functionality, excessive permissions, and excessive autonomy.
Read that list again. None of those three is about how good the model is. They are all about what you handed it.
That is good news for a business owner. You do not need to predict model behavior to make a sound decision. 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 principle underneath is old. 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. Same rule.
Four access tiers, from least to most
Most access debates stall because access to the CRM gets treated as one switch. It is not. There are at least four meaningfully different levels, and most workflows 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
There is a fifth level, unattended write, where the agent completes actions with no review at all. That is a decision to make later with evidence in hand, not a starting position.
The tiers are real, not a metaphor
Your systems already expose this ladder. Google's Gmail API scopes are a useful example because they are published and specific:
- gmail.metadata views message metadata such as labels and headers, but not the email body.
- gmail.readonly views messages and settings.
- gmail.compose manages drafts and sends email.
- mail.google.com reads, 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 is this entire article in miniature. The narrow options already exist. Broad access usually gets requested because it is easier to build against, not because the job requires it.
So the useful question in a vendor conversation is not whether the agent is secure. It is which exact scopes will be requested, and what breaks if you grant the next one down.
Start at the lowest tier that still finishes the job
Here is the test worth running when you scope a workflow.
- Write down the finished output first. Not handles the inbox. Something like: 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 rule is arbitrary on purpose. It moves the conversation onto real effort instead of theoretical convenience. If clicking send is the only manual step left, you have automated the work and kept the judgment.
If you have not chosen a workflow yet, our guide to AI agent use cases for business covers role selection and a scorecard for the first workflow, and where AI fits into existing workflows covers whether a workflow suits an agent at all.
Do not ask the model to enforce the rule
This is the mistake that survives longest, because it looks like it is working.
An instruction like never send an email without approval lives in the prompt. It is a request, not a control. 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 three things.
- The credential the agent uses does not carry the permission you do not want exercised. If it should never delete, the token cannot delete.
- Approval gates live in the workflow or the destination system, not in 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 direction. The boundary belongs in the plumbing.
Reading is not risk free
There is a comfortable assumption that read only access is harmless. It is safer. It is not free.
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 own worked example is a mail assistant. The extension it uses can both read and send. A crafted incoming email tricks it into scanning the mailbox for sensitive information and forwarding it to the attacker. The read was the entry point. The send permission was the damage.
That is why tiers matter 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 want a live example of guardrails failing under exactly this kind of pressure, we broke one down in the Grok-BankrBot hack and the guardrails every AI agent needs.
Keep these behind a person at launch
Whatever tier you land on, some actions should require a named human approver from day one:
- 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
That last one gets missed most often. An agent that can widen its own access does not really have an access boundary.
A per system access worksheet
Fill this in once per system, before anything is connected. Seven fields.
- System and identity. Which system, and the exact account the agent will use. Not a shared login.
- Tier requested. One of the four above, in writing.
- Scope boundary. Which mailbox, folder, pipeline, board, or table. Not the CRM.
- 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 do it today, and how long it takes.
Field seven is the one nobody fills in until they need it. Test it before launch, not during an incident.
Access should change after launch, in both directions
The first grant is a hypothesis. Treat it like one.
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 is pure downside.
Removing access later takes someone noticing, scheduling the change, and confirming nothing depends on it. That work competes with everything else on the list, which is the practical argument for starting narrow. Widening 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, reviewed by whom. OWASP's Top 10 for Agentic Applications is the reference to hand a technical partner when you want the longer list of risks behind that review.
What this looks like in a managed AI employee
This is the work VantaSoft does 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, and those decisions are recorded in the Order Form rather than left to whoever happens to configure the integration. Agents run in a customer specific managed environment. Where a read only path is enough for the job, we use the read only path: 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. What a boundary does is make the limit explicit, reviewable, and revocable, which is the difference between a control and a promise.
Frequently asked questions
Should an AI agent have its own login, or use an employee's account?
Its own. A distinct 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?
Safer, not safe. Read only removes the ability to act, which is where most damage lives. It does not remove exposure of whatever the agent can read, and it does not stop hostile content from influencing the agent's output. Scope the read as well.
Can we grant broad access now and tighten it later?
You can, but the tightening rarely gets scheduled, and by the time anyone looks at it something may depend on the extra permission. Starting narrow costs one conversation. Widening later is a short change with a documented reason.
What if a vendor cannot say exactly what access it needs?
That is a scoping answer, not a security answer. If the workflow is defined, the access list is derivable from it. 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. Smaller teams have fewer people positioned 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
The businesses that get real work out of AI employees are not the ones that trusted the most. They are the ones that decided, per system and per action, what the agent could see, what it could do, and who signs off.
If you want help drawing those lines around a specific workflow, that is what a discovery session is for. It starts with 30 minutes on your workflows. Start Automating.
