An AI agent does not become risky because it can think.
It becomes risky because it can act.
Reading a document is one thing. Changing it is another. Drafting a refund message is one thing. Issuing the refund is another. Comparing vendors is one thing. Signing a contract is another.
Permissions are the bridge between usefulness and danger. If they are too narrow, the agent becomes a summarizer trapped behind glass. If they are too broad, the agent becomes a fast intern with the keys to rooms nobody meant to open.
The answer is not “trust the agent” or “never trust the agent.” The answer is a ladder.
The permission ladder
Most agent permissions can be arranged from safest to riskiest:
- Read: inspect files, pages, records, or tickets.
- Draft: write proposed text, code, plans, or messages.
- Edit with undo: change controlled material where rollback is easy.
- Submit for approval: prepare an action that a person confirms.
- Act within limits: take low-risk actions inside a policy.
- Act autonomously with audit: handle routine work with logs and review.
The mistake is jumping from step one to step six because a demo looked impressive.
Good systems earn their way up the ladder. They start by reading and drafting. They move into edits when review is easy. They get narrow autonomous authority only after the work is boring, bounded, and measured.
The three questions before granting action
Before an agent can act, ask three questions.
First: is the action reversible?
Renaming a draft file is different from deleting a customer record. Posting a private comment is different from sending a public announcement. Reversibility is not only technical. It is social. You can undo a calendar invite, but you may not undo the confusion it caused.
Second: does the action touch sensitive data?
Private customer information, medical details, financial records, employment data, credentials, legal documents, and personal messages deserve stricter gates. Even if the agent is trying to help, it may quote the wrong detail in the wrong place.
Third: does the action create an obligation?
Money movement, purchases, refunds, commitments, contracts, policy promises, hiring decisions, and messages sent under a person’s name all create obligations. Those are approval-gate territory until the process is exceptionally mature.
Approval gates should be specific
“Ask before doing anything important” sounds safe but is too vague.
Better gates are explicit:
- “Ask before sending any external message.”
- “Ask before spending more than $25.”
- “Ask before editing published pages.”
- “Ask before changing permissions or credentials.”
- “Ask before deleting, archiving, or overwriting records.”
- “Ask before using data from outside the approved source list.”
The agent should not have to guess what “important” means.
Logs are not optional
If an agent acts, it should leave a trail.
At minimum, the log should answer:
- What goal did the agent receive?
- What sources did it inspect?
- What tools did it call?
- What decisions did it make?
- What did it change?
- What approvals did it request?
- What failed?
Logs are not only for blame after something goes wrong. They are how the system learns. A good log turns a mysterious agent mistake into a fixable workflow problem.
A customer refund example
Consider a support agent handling refund requests.
At level one, it reads the ticket and order history. At level two, it drafts a reply and recommends a refund decision. At level three, it fills a refund form but does not submit it. At level four, it asks a person to approve the refund. At level five, it can issue refunds under $20 when the order matches a known policy. At level six, it handles routine refunds autonomously, but exceptions and random samples are reviewed.
That ladder is slower than giving the agent full control on day one.
It is also how you avoid teaching the organization to fear the tool.
The permission review
Agent permissions should expire, or at least be reviewed.
Workflows change. Tools change. Policies change. People leave. A permission that made sense during a pilot may become reckless after the agent is connected to more systems.
Use a regular review:
- List every agent.
- List every tool and data source it can access.
- List every action it can take without approval.
- Check whether those permissions still match the real task.
- Remove anything the agent no longer needs.
The safest permission is the one the agent never receives.
The real goal
Permission design is not there to make agents timid. It is there to make their authority understandable.
An agent with a clear lane can work quickly because everyone knows what it can touch. An agent with vague authority creates hesitation. People stop using it, or worse, they use it without knowing what it is doing.
The best agent systems make permission visible: read, draft, edit, approve, act, audit.
That ladder is where trust becomes operational.
