Connecting an AI workflow to a business tool is not one decision. Reading a mailbox, creating a draft, changing a record, sending a message, and deleting a file are different capabilities with different consequences. A useful permission review separates those capabilities before anyone authorizes a connection.

This worksheet helps United States small businesses review access for one bounded AI workflow. It is an operating exercise, not legal or cybersecurity advice. Local AI Developer scopes Mac mini-based systems around approved tools, readable business instructions, and human approval boundaries. The privacy questions guide covers broader buying questions, while the Orange County AI automation page explains the local scoping process within a nationwide service.

Begin with the output, not the account

Write down the single output the workflow is expected to produce. It might prepare an internal intake brief, assemble an exception list, or draft a source-linked update for review. Then name the person who receives that output and the decision it supports.

Avoid beginning with “connect the shared inbox” or “give it access to the drive.” Those statements name systems, not the work. A system may contain far more information and authority than one output requires.

List actions that remain outside the workflow. If the system prepares a draft, say whether it is prohibited from sending, changing a customer record, accepting an order, setting a price, or deleting source material. An explicit exclusion gives the permission review a boundary it can test.

Separate reading, preparing, and acting

Create a row for every capability the workflow might use. Distinguish read, search, create, update, send, move, share, and delete. Do not collapse them into a single label such as “email access” or “CRM access.”

For each capability, record why it is needed. Reading messages in one approved label may be necessary to prepare an intake brief. Sending from the same mailbox may not be necessary at all. Creating a draft can be useful while changing the source record remains behind human review.

Where a connected service offers only broad permissions, record that fact. A broad technical grant does not expand the approved business scope. It means the workflow needs additional controls, monitoring, or a narrower alternative before use.

Identify the exact resource boundary

Name the account, shared drive, folder, mailbox label, calendar, project, or view the workflow may use. “Company documents” is not specific enough for an operator to verify or an administrator to reproduce.

Record resources that look similar but are excluded. A workflow designed for a support mailbox should not silently search an executive mailbox. A project-folder workflow should not treat every file visible to the connected account as an approved source.

Use stable identifiers where the tool provides them. Display names can change or be duplicated. The worksheet can include a readable name for operators and a non-secret resource identifier for configuration and testing.

Assign a business owner and an access owner

The person who owns the workflow's business outcome may not be the person who administers the connected tool. Name both. The business owner decides whether a capability is necessary; the access owner provisions, reviews, and revokes the connection.

Also name the source owner for important information. That person decides which folder, view, or record is authoritative when sources disagree. Access does not establish authority over content.

Define an absence fallback. If the usual reviewer or administrator is unavailable, state whether a named backup may act or whether the workflow waits. The system should not infer authority from whoever happens to have access.

Build a capability matrix

For each connected resource, capture:

Mark each capability required, optional, or prohibited. If an optional permission cannot be removed technically, explain how its use will be prevented and detected. Do not describe an unwanted capability as harmless merely because the first test did not exercise it.

Keep credentials out of the worksheet

The worksheet should name connections and owners without containing passwords, API keys, session cookies, recovery codes, or access tokens. Store secrets through the business's approved credential process.

Document how an authorized administrator can identify the connection, inspect its granted access, and revoke it. Record the account or service role responsible for that process, not the secret itself.

Make sure error messages and operating notes also avoid secret values. A useful failure record can identify the connection, attempted operation, time, and error category without exposing credentials.

Place approval before consequential actions

Decide where a person must review the proposed action and its source evidence. External messages, customer commitments, record changes, permission changes, and deletion are reasonable places to require an explicit business decision.

Approval should identify the item and proposed action. A general statement that the workflow is approved does not authorize every future draft, recipient, or record change. Keep content approval separate from delivery when those are different responsibilities.

Record what happens when approval is denied, times out, or is unavailable. The item may remain on hold, return for correction, or move to the manual process. It should not continue simply because the workflow has technical permission.

Test allowed and denied behavior

Create a test case for each required capability. Confirm that the workflow can reach the exact approved resource and produce the expected intermediate result. Inspect the source reference and resulting record, not just the final prose.

Then test prohibited actions. Ask the workflow to use an excluded folder, update a read-only record, send without approval, or act for an unrecognized requester. The expected result should be a clear refusal or hold with no side effect.

Test a confusing case as well: two similarly named folders, a forwarded message from outside the approved label, a recipient not on the approved path, or a record whose ownership changed. These cases reveal whether the boundary depends on a name, assumption, or remembered chat instead of a reproducible rule.

Verify side effects independently

Do not rely only on the workflow's statement that an action succeeded or did not occur. Inspect the connected system. Check whether a draft, sent item, modified record, shared file, or deleted object exists.

Use a stable item identifier to connect the workflow record with the source and destination. Record the attempted capability, result, reviewer, and time. This helps an operator distinguish a failed request from an action that completed before a timeout.

Include duplicate and retry tests. If a connection fails after creating an output, the recovery path should check for that output before trying again. Repeated execution should not create duplicate messages or records where the connected tool supports a reliable check.

Review access when the workflow changes

Repeat the permission review when a new source, output, destination, user group, model, or connected tool is proposed. A workflow that starts by reading one folder should not inherit authority to update an entire system because a later feature would be convenient.

Compare approved capabilities with actual use. An unused permission may be removable. A frequently requested capability may justify a scoped change, but only after the owner documents the need, tests it, and updates the approval boundary.

Review the connection when an owner changes roles, a contractor leaves, or the workflow is paused. Preserve readable business instructions and required records while revoking access that no longer has an approved purpose.

Complete the permission review

For one workflow, document:

Use the completed worksheet when comparing the available Local AI Developer packages. A permission boundary that can be read, tested, and revoked is more useful than a broad connection whose authority exists only as an assumption.