Before an AI assistant gets business access, review the whole workflow
Share
Published
Before an AI assistant receives business access, review the whole workflow: the information it can read, the actions its tools can take, the people who approve those actions and the way access ends. A reassuring answer from the assistant does not establish that these limits exist in the connected systems.
A useful review starts with a narrow task. “Draft a reply to an order query” is easier to assess than “help with customer service.” The broader description can quietly include reading unrelated mail, changing records and contacting customers.
Describe the job before choosing permissions
Write one sentence stating the intended result. Then list the inputs required to produce it. For a draft reply, that might mean an approved knowledge base and the relevant support record. It does not automatically require the entire mailbox, every customer file or the ability to send the draft.
Record the person who owns the workflow and the person who controls the connected account. Those may be different people. A department manager can explain the business need while an administrator verifies which permissions the system actually grants.
The NIST Generative AI Profile provides a voluntary risk-management reference. The process here is an original operational review for a small team, not a claim of NIST certification or a substitute for the organisation’s applicable obligations.
Separate reading, drafting and acting
| Capability | Question to ask | Evidence to inspect |
|---|---|---|
| Read information | Which records and fields can the connection reach? | Account permissions and a contained test |
| Create a draft | Where is the draft stored and who can see it? | Draft location and access settings |
| Change a record | Which fields may change, and can the action be reversed? | Tool scope and change history |
| Send or publish | Who approves the exact destination and content? | Enforced approval and delivery controls |
| Delete | What can be removed, and what recovery exists? | Permission scope and tested recovery route |
A permission described as read-only can still expose information to the model or a service handling the task. Review the information flow as well as the absence of write access. For a system that can act, examine the controls around consequential actions rather than relying on a sentence in the prompt.
Use a permission register that can be challenged
For each connection, record the account, information scope, allowed action, owner, approval requirement, logging, review date and revocation method. Include limitations you cannot yet verify. “Vendor says access is limited” should lead to a request for the relevant configuration or documentation.
The AI permission-register template includes a worked support-assistant example. Its value is in making the proposed access specific enough for someone else to disagree with it or test it.
Keep credentials out of the register. It should identify the connection and its owner, not provide a password, token or recovery code that allows another person to reuse the access.
Find out where information goes after the response
Ask where source material, prompts, outputs, logs and attachments are stored. Review the provider’s current terms and configuration for the service and plan being used. A consumer account, a managed business account and a separate integration can have different arrangements.
Include the tools around the model. A meeting assistant can create a transcript, save a recording, generate a recap and pass material to another application. The meeting-transcript guide explains why access to the meeting and access to its later records need separate review.
Similarly, a PDF that appears redacted may still contain information the sender intended to remove. Check the redaction workflow before using such a document as an AI input.
Test with material you can afford to expose within the test
Create fictional records, a controlled test account and an approved destination for any output. Do not begin with a real customer database merely because it is available. Keep external delivery disabled or restricted by the connected system during the test.
Include a case the assistant should refuse or escalate, a record outside its permitted scope and an ambiguous instruction. Inspect the tool result and resulting record, not just the assistant’s explanation of what it did. The synthetic-records testing guide shows how to prepare a small test pack.
Define the approval moment
An approver needs the proposed action, affected record, destination and relevant source evidence. “Approve the assistant’s work” is too broad if the system later changes the recipient or attaches another file.
For a workflow that drafts customer replies, keep sending as a separate step until the organisation has assessed the consequences and implemented the controls it requires. For payments, access changes, deletion and public publishing, involve the appropriate authorised decision-maker.
Our guide to reward hacking and permission checks explains why a performance target should be supported by evidence of the actual outcome.
Make revocation part of the trial
Before approving the pilot, demonstrate how the owner would disable the connection and stop queued work. Check whether revoking an account permission also stops a running job or whether the service requires another action.
Record what happens to existing drafts, exported files and retained logs. Revocation limits future access; it does not itself prove that every previously created copy has been removed.
Review changes that alter the risk
Repeat the relevant checks when a new tool is connected, the assistant receives a larger data scope, automatic delivery is enabled or the provider changes a material handling term. A pilot approved for draft summaries should not silently become an assistant authorised to email customers.
Close the review with a written decision: approved scope, unresolved limits, responsible owner and next review trigger. Keep the evidence somewhere a successor can find it.
The UK regulator’s agentic-AI call for evidence, closing on 20 November 2026, asks related questions about security and accountability. It is an ongoing consultation, rather than final guidance or approval of a particular workflow.
What is the minimum useful first step?
Choose one task, identify its smallest necessary data scope and test it in a contained environment. If the team cannot explain the access or demonstrate how to stop it, resolve those gaps before connecting production records.
Featured image: AI-generated conceptual illustration.
