Give the assistant permission for a specific job
Decide what an AI assistant may read, which changes it can make and when a person must approve an action before you connect it to business software. Start with one workflow and describe the smallest amount of access that would let it finish. Enforce those limits in the application that owns the data.
“Help with client follow-ups” could mean reading a task list, drafting a reminder, adding an internal task or sending a message to a client. Those are different operations with different consequences. The design should make them separate choices. A good assistant can be useful with permission to do the first two while the business decides when to allow the others.
Walk through a documented SelfManager.ai workflow
SelfManager.ai is a product built by abZ Global. Its public connection guide shows a small workflow worth examining: read the tasks on a specified day, then ask the assistant to add a follow-up task to a named table. The example uses a task called “Send the revised proposal.” Creating that task is an internal reminder. The words in the reminder do not authorise sending a proposal.
In the read step, the assistant retrieves the chosen day and reports what it found. The user can compare the answer to the app before relying on it. In the write step, the user supplies the destination table, date and wording. If the table is missing, the guide tells the user to decide whether the assistant may create one or should ask. That small choice matters. A request to put a task in a known place can otherwise turn into permission to create new containers whenever a lookup fails.
SelfManager’s documented permissions separate ordinary writes from actions such as writing to shared tables or deleting supported items. A user can connect without permission to make changes. Sharing and changing who can see a table remain actions in the application. This gives a useful pattern for a business tool: distinguish the user’s access to the account from the subset of that access delegated to the assistant.
Write down four decisions for each action
- Who and what can it reach? Name the connected account, the records it may access and which people may see the result. A user who belongs to several teams may only want the assistant working with one project. Reading a task title may be sufficient without opening every attachment or comment.
- What change may it make? Describe the action in business terms. “Create one draft follow-up task on this project” gives a system something it can validate. “Manage the client” leaves the scope open.
- When must it stop for approval? Use the consequence to choose the threshold. Adding a private note differs from writing on a shared account, notifying someone or deleting the last copy of a file. Reviewers need to see the actual destination and proposed change to make a useful decision.
- How will someone verify the result? Decide what counts as success, what appears in the activity log and what a person can do if the operation only partly succeeds. A record of the action is more useful than a chat message saying “done.”
Keep these decisions in a short action inventory. For an initial internal follow-up workflow, the inventory could allow reading tasks for one authorised project, allow adding a private task with a stated date and require approval for a shared comment. Email sending can stay outside that integration’s available actions. The inventory then becomes a specification an engineer can test and a business owner can review.
Enforce access where the action happens
Instruction text can guide an assistant. The service receiving the tool call still needs to decide whether the action is allowed. Check the identity, the connection’s permitted actions and the user’s current access to the target record when the operation runs. This last check matters when someone leaves a team or a table changes from private to shared after the assistant first reads it.
Treat material the assistant retrieves as data. An instruction written in a task, a document or an incoming support message does not grant permission to act. If a customer uploads a document that tells an assistant to export other accounts, the export should be unavailable or rejected by the system. This is easier to enforce when the available tools expose narrow operations instead of a general credential with broad account access.
Test the boundary with a real denied request in a controlled environment. Connect with read access, then attempt a write through the integration. Test an allowed write to one project and the same write against another project the connection should not reach. For shared actions, change the target after the user sees the preview and verify that the old approval cannot silently authorise the new action.
Design approvals for the action being taken
A useful approval prompt tells the reviewer which record will change, what will be written and who can see it. If the effect includes a notification or publication, show that too. The reviewer should be able to notice the wrong customer, the wrong date or an unexpected audience without having to read the entire conversation.
Require a fresh decision if a material detail changes. Suppose an assistant prepares a comment for a private task, then discovers that the only matching table is shared. The destination and audience have changed. A new preview gives the user a chance to decide whether that comment still belongs there.
Too many prompts can make approval mechanical. For repetitive, low-impact work, let the team authorise a bounded rule. One example is adding internal follow-up tasks to a fixed project with no outbound notification. Keep stronger gates for changes with different audiences, irreversible effects or meaningful commitments. The same workflow can move from supervised to more automatic as the team observes successful outcomes and tests the edge cases.
Plan for interrupted requests and unclear results
A connection may time out after the application accepts an action. Retrying blindly can add the same task twice. Give the write a stable request identifier so the service can recognise a retry of the same operation, then read the resulting record before reporting success. If you cannot tell whether the action happened, expose that uncertainty and reconcile it before retrying a consequential write.
Keep a way to revoke access and check that revocation takes effect for subsequent requests. Keep the audit trail useful to the people who operate the system. A team lead should be able to see which account and integration changed a record and when, without a log that unnecessarily copies sensitive document contents.
Begin with a workflow someone already understands. Compare the assistant’s read result to the app, try one narrow write, check the record and test a rejection. Add scope after the business can explain why it needs that next action and how it will verify the result.
Frequently asked questions
Should an AI assistant start with read-only access?
Read-only is a practical starting point when the job is to find, summarise or compare information. Add a narrowly defined write when the workflow needs to change a record and you can test the permission boundary.
What is the difference between a permission and an approval?
A permission determines whether the integration can perform a type of action. An approval authorises a particular action with a particular destination and effect. Sensitive operations can require both.
Does using MCP enforce the business’s permissions automatically?
MCP provides a way for assistants to call tools. The connected application still needs to enforce account access, operation permissions and any approval requirement.
What should an assistant do if a write times out?
Check whether the intended change already exists or retry with the same request identifier if the service supports it. Report success after verifying the result.