What Should Your AI Agent Actually Be Allowed to Do?
Give an AI agent wide access to look things up. Give it a short, specific list of things it's actually allowed to do on its own. Most of what goes wrong in a small business AI agent build isn't the agent giving a bad answer. It's the agent being allowed to act on that bad answer before anyone sees it, because nobody drew a line between what it can see and what it can touch.
A support bot pulling up a customer's order history is low risk. The same bot issuing a refund with no second check is a different kind of access, and a lot of builds hand out both the same way, through the same integration key, with the same amount of thought.
What Counts as Reading Versus Acting
Reading is the agent looking something up, an order status or a customer's history. Nothing changes on the other end. If it reads something wrong, the worst case is a wrong answer, and a person can catch it before it does damage.
Acting is the agent changing something, sending an email or issuing a refund. A wrong act doesn't wait for someone to notice. It just happens, and by the time anyone checks, the outcome is already real.
Why Lumping the Two Together Causes Real Damage
OWASP's Gen AI Security Project ranks this under a risk it calls Excessive Agency, one of its top risks for AI systems that can take action. It names three separate causes: the agent has more functionality than its job needs, the systems it connects to give it more permission than its job needs, or it can take high-impact actions with nobody checking first.
Limit the permissions that LLM extensions are granted to other systems to the minimum necessary in order to limit the scope of undesirable actions.
An agent built to answer billing questions needs read access to an invoice. It doesn't need the same integration key to also be able to void one. If both live on the same key, a hallucinated policy line or a misread date doesn't stay a wrong sentence someone can fix. It becomes a real charge, reversed.
What's Usually Fine to Let an Agent Do on Its Own
Look up an order, account, or policy detail
Answer a question from what it was actually trained on
Draft a reply for a person to send
Reschedule inside rules you already set, same slot type, same calendar
Flag something for a human instead of guessing
What Should Always Wait for a Person to Say Yes
Refunds and anything that moves money
Deleting a record or cancelling an account
Sending to your full list or a large group at once
Changing a price, a contract term, or a policy
Anything that can't be undone once it's sent or run
How to Draw That Line in a Build You Already Have
Write down every system the agent actually touches: CRM, email, payment processor, calendar, anything else.
Mark each one read or act. No middle category.
For each act permission, ask if a wrong read could turn into money moving, a record changing, or a message you can't pull back. If yes, put a person in front of it.
Cut anything the agent doesn't need for the job it's actually doing, even if the integration made it easy to grant everything at once.
An agent that stays inside read access and reversible actions is worth seeing in practice. demo.ajmarketingresults.com is one, trained on this site's own content, and it will tell you plainly when something is outside what it was given to work with.
Frequently Asked Questions
Does This Only Matter if the Agent Touches Money?
No. Deleting a record or sending something to a big list you can't unsend carries the same risk with no dollar sign attached.
What's the Fastest Way to Check What My Current Agent Can Already Do?
Pull the actual permissions on the integration key or API connection, not the instructions in the prompt. A prompt that says don't issue refunds doesn't stop the key underneath it from being able to.
Does Cutting an Agent's Actions Make It Worse?
It makes it a tool scoped to its actual job instead of one that happens to have more access than anyone checked. The parts it still does, it does the same.
How Is This Different From Setting an Autonomy Level?
An autonomy level is about how much decision it makes without you in the room. This is about which systems it can technically reach at all. Check both separately. How Much Autonomy Should You Give AI in Your Business? covers the first question.
Comments