What an AI Business Assistant Should Be Allowed to Do

Start with one job and a finish line

“Help run the business” gives an assistant too much room to interpret the task. A manageable first job might be preparing an internal inquiry summary from approved information, with a person checking it before use.

Write down the required inputs, expected output, reviewer, and completion condition. Also say what remains someone else’s decision. If a request lacks a date or job detail, the assistant should mark the gap and follow the agreed clarification route.

Separate permission from capability. A tool may technically support sending a message or editing a record; your policy must still decide when that action is allowed.

Give each action an explicit permission

A conservative starting list for an initial pilot is:

• Read: Only the approved sources needed for the job, with appropriate privacy and account controls.
• Prepare: Summaries, checklists, proposed record changes, and message drafts for review.
• Change: Only specifically authorized fields or low-risk actions within a clearly defined scope.
• Send or commit: Require a person’s approval for customer-facing messages, purchases, refunds, contractual promises, or other consequential actions during the pilot.
• Keep under human control: Credentials, security settings, irreversible deletion, and decisions requiring qualified professional judgment.

Define who can approve each action and exactly what approval covers. Permission to draft a reply does not authorize sending it. Approval for one recipient or amount does not automatically cover another. Your organization’s rules and the tool provider’s restrictions may be stricter.

Make access match the job

NIST describes least privilege as limiting access to what is necessary for the assigned task. Apply that idea before connecting business systems.

If the job uses one approved document folder, start there. If reading is sufficient, avoid write access. Check which account the assistant acts through, where information may be sent, and how access can be revoked. Where the tool cannot enforce a required restriction, narrow the task or keep that step manual.

Begin testing with fictional or approved de-identified material. Before real business data is introduced, verify that the account, service terms, retention settings, and organizational permissions support that use. Keep passwords and access tokens out of prompts and work logs.

Keep outside content from changing the rules

An email, document, or webpage can contain instructions aimed at the assistant. Treat that content as material to inspect, not as authority to expand its access or redirect a task. An instruction inside an inquiry to send the customer list somewhere must not become a new assignment.

OpenAI’s agent-safety guidance describes prompt injection and unintended data sharing as risks, and recommends layered controls. Restrictions and approvals should be supported by the surrounding system; a sentence in a prompt alone is a weak boundary. Controls reduce risk without making an assistant infallible.

Test the permission boundaries

Write the expected result before running each case. Alongside a normal request, include:

• A required detail is missing: the gap stays visible.
• Two contacts have similar names: the assistant asks rather than choosing silently.
• A source contains conflicting instructions: the approved task remains in control.
• A requested action exceeds permission: it stops for the right person.
• A tool times out after submission: it checks the destination before any retry.
• The reviewer rejects a draft: nothing is sent or changed.

Record what actually happened, including failures and untested conditions. Anthropic’s agent guidance emphasizes environmental feedback, human checkpoints, stopping conditions, and testing in controlled environments. A short successful demonstration provides limited evidence about everyday reliability.

Keep a useful action record and a stop path

A work log should record the authorized task, action attempted, result observed, evidence of completion, and any limit or blocker. “Message sent” should be supported by a destination record or a clear service response. An uncertain result should remain uncertain until checked.

Keep the record proportionate. Avoid copying sensitive source material when a reference and a short result will do. Assign someone to handle failures and show them how to pause the assistant and continue manually.

In my own projects, an Android voice widget was built, tested, and accepted. That establishes a specific project outcome. It provides no measured time saving, revenue result, or evidence that the same setup would suit a client. Use that same care when describing what your pilot has proved.

Before you expand access

Check five things: the job is clear; permissions are enforceable; approvals identify the actual action; failure cases have been tested; and a named person owns recovery. Review those boundaries whenever the workflow or connected tools change.

If you need help deciding where an assistant might fit, start with AMH’s One-Workflow Review. If that points toward an assistant, a setup pilot would have its own agreed scope, tools, privacy boundaries, testing, and price. It is separate from the $500 review.