AI Agent Permissions: Decide What Needs a Human Before You Connect the Tools

An AI agent can draft an excellent customer email and still be the wrong system to decide when to send it.

That distinction gets lost when an evaluation focuses on answer quality. A convincing demo shows that an agent can interpret a request and complete a workflow. It does not establish which parts of that workflow the organization should authorize it to perform independently.

The useful governance question is: "Which actions can happen without a human decision, and under what conditions?"

You can answer that before choosing a model or buying an agent platform. Start with the actions, the systems they affect, and the consequences of getting them wrong. Then turn those decisions into enforceable permissions.

Inventory actions, not job titles

"Sales assistant" is a role description. It is not a permission boundary.

A sales workflow might involve reading an account record, adding an internal note, changing an opportunity stage, drafting an email, and sending that email. Giving the agent "CRM access" hides several materially different decisions inside one phrase.

Build an action inventory before connecting credentials. For each proposed task, record:

• The exact operation and target system.
• The records or fields the agent needs.
• The possible downstream effects.
• Whether the action can be undone, including consequences outside the system.
• The person accountable for allowing it.

Use verbs that map to actual operations. "Manage opportunities" is too broad. "Add a proposed next-step note to assigned opportunities" is something you can evaluate and test.

Do not assume an operation is harmless because its name sounds administrative. Updating a CRM field could trigger an email workflow. Adding someone to a campaign could schedule future outreach. Classify an action by its effective consequences, including automation it activates.

Use read, write, and external commitment as the starting boundary

A useful first pass separates access into the following classes. These are policy starting points, not universal defaults.

Action class	Example	Starting policy
Read	Retrieve assigned account history	Allow within a defined data scope if the task requires it
Internal write	Save a draft or add a proposed note	Consider allowing where the effect is bounded and recoverable
Consequential write	Change account ownership or a field that triggers automation	Require approval or narrowly defined, tested conditions
Send or publish	Email a prospect or publish a campaign	Require approval of the specific outbound action
Pay or otherwise commit resources	Issue a refund or submit a purchase	Keep disabled unless explicitly needed; define separate authorization if enabled

This classification prevents a common mistake: treating every write as equivalent.

Saving an unpublished draft and sending it to a customer might use adjacent API endpoints. Their consequences are different. A draft can usually be reviewed before it affects anyone. A sent message can be corrected, but the recipient has already received it.

Payment belongs in a separate decision even when the interface makes it look like another tool call. Approval to communicate should never imply approval to spend.

For an initial deployment, a defensible posture is scoped reading, limited internal drafting, and explicit approval before external commitment. Expand from there when you have evidence that a particular action warrants more autonomy.

Read permission still needs boundaries

Reading does not modify the source record, but it can expose information to components involved in processing the request.

Before granting read access, decide which data the task actually requires. An agent preparing account follow-ups may need selected contact fields and recent account activity. That does not automatically justify access to every attachment, billing record, or unrelated customer.

Check the entire processing path: retrieval, model input, tool responses, logs, and any retained working context. Read-only access to the source system does not answer where retrieved information travels or who can later inspect it.

Also treat retrieved content as data, not authority. An email, web page, or customer note may contain text telling an agent to change its instructions or use another tool. That text should not be able to expand the agent's permissions.

A practical test is to place an instruction in a test record asking the agent to retrieve an unrelated restricted record. The permission boundary should reject the attempted access regardless of whether the model follows the instruction.

Decide which internal writes can run unattended

Human approval for every draft save creates work without necessarily reducing meaningful risk. The goal is to put review where it changes the outcome.

For each internal write, ask:

1. Is the target tightly scoped?
2. Can the change be reversed with a known recovery procedure?
3. Can it activate another workflow or influence an important decision?
4. Can repeated execution create duplicates or accumulating damage?
5. Will a person see the change before relying on it?

These answers should produce a specific policy.

For example, you might allow an agent to save a proposed follow-up in a draft field on assigned accounts. You might require approval to overwrite an existing contact address because a bad change could misdirect later communication.

"Internal" is not a synonym for "low risk." An inaccurate support note could influence the next employee's response. An incorrect opportunity stage could affect reporting. Some internal writes need review even when nothing immediately leaves the organization.

Where possible, separate proposals from authoritative records. Let the agent suggest a change without granting permission to replace the value that other workflows trust.

Define approval as a specific transaction

An approval gate is useful only if the reviewer can tell what they are authorizing.

"Approve the next step" is insufficient. For an outbound email, the review should show the destination, sending identity, exact content, and attachments. Include relevant source context so the reviewer can check factual claims without reconstructing the workflow.

The approval should bind to that specific action. If the recipient, content, attachment, or other material parameter changes, the action needs fresh approval.

Use this pattern as an implementation and procurement checklist:

• The agent prepares a proposed action.
• A policy check determines whether the action is allowed, blocked, or requires review.
• An authorized reviewer inspects the proposal.
• The execution layer verifies that approval still applies to the exact action being attempted.
• The system records the result, including failure or uncertain delivery.

The execution layer matters. A prompt that tells an agent to ask permission is a behavioral instruction. It should not be the only control protecting an outbound capability.

Check alternate routes too. Blocking one email tool does little if the same credentials can send through another endpoint or trigger a campaign that sends later.

Expired, rejected, or missing approval should leave the action unexecuted. Retries also need attention: approval for one send should not silently become authorization for duplicate sends after a timeout.

Give reviewers a decision they can realistically make

Human review has a cost. Every gate adds delay and consumes attention. Poorly designed gates can become a queue of habitual clicks.

Assign a reviewer who understands the action and has authority over its consequences. For a customer response, that may be the person responsible for the account or support case. Resource commitments may require a different owner.

Make the review screen answer practical questions:

• Who or what will be affected?
• What exactly will happen?
• Which source records support the proposed action?
• What assumptions or unresolved questions need checking?
• Has a similar action already executed?

An explanation of why the agent chose an action can help orient the reviewer, but it is not proof that the action is correct. Show the underlying evidence.

Measure review burden during a pilot. If reviewers cannot examine proposals carefully at the expected volume, reduce scope or improve the review context. Removing gates merely to clear a backlog changes the risk decision; it does not solve the review problem.

Test permissions with deliberate failure cases

Do not accept a successful demonstration as evidence that the boundary holds. Use test accounts and controlled destinations to attempt actions that should fail.

A compact acceptance checklist:

• Request a record outside the role's assigned scope.
• Attempt to modify a field the role can only read.
• Try sending without approval.
• Approve a draft, then change its recipient before execution.
• Attempt an outbound action through an alternate tool or workflow.
• Retry an action after a simulated timeout.
• Revoke permission while an action is waiting for approval.
• Put instructions in retrieved content that ask for broader access.

For each test, define the expected outcome before running it. Capture whether execution was prevented and whether the record explains what happened.

Distinguish "the model declined" from "the tool or execution layer denied the operation." Both are useful observations. The latter is the stronger evidence that a permission boundary is enforced.

Where our own product lands on this

EMS, the Employee Management System in Adaptive IP Services' Hub division, uses a conservative boundary for outbound activity: a human approves every outbound action.

EMS lets organizations onboard and manage AI virtual employees for sales, marketing, and support. Each virtual employee is isolated and has a role. It pairs with the CRM to support an acquisition loop.

In the framework above, that per-role approval-gate model puts human review at the point where work leaves the organization. It is a concrete answer to the outbound-permission question, with an explicit review burden attached.

That description does not settle every implementation question. Buyers should still use the checklist above to examine data scope, internal changes, approval behavior, and enforcement. Those are evaluation criteria, not additional EMS capability claims.

Write the policy before the pilot

Choose one role and one bounded workflow. List every operation it needs, classify the consequences, and name the reviewer for anything requiring approval.

For each allowed operation, document its scope and failure behavior. For each approval gate, specify exactly what the human must see and what changes invalidate approval. Then run the failure tests before introducing real recipients or consequential records.

The policy is ready when another person can use it to predict which actions will execute, which will wait, and which will be denied.

Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm.

David J. Boggs
Founder and CEO, Adaptive IP Services

Learn more about EMS