Before you connect an AI assistant to your work accounts

An AI assistant offers to connect to your work account. The useful question is what that connection would allow it to read or change, and whether that access fits the job you have in mind.

Signing in is only part of the decision. You also need to consider the service account, enabled tools, where information will be processed and how you will end the connection when the work is finished.

This guide gives you a practical review you can use with an administrator or on an approved test account. It does not assume every connector has the same permission controls.

Begin with a job small enough to describe

For example, suppose you want an assistant to compare three internal help articles in one project documentation space. The output is a list of conflicting instructions for a human editor to review. It does not need to search customer records, rewrite the articles or send a report.

Write that purpose down before opening the sign-in screen. It gives you a reason to accept or question each requested capability. If the service cannot restrict access to the intended space, that is a design constraint to resolve, rather than something a prompt can fix.

Separate three controls

These controls may interact, but they are not interchangeable. Hiding a write tool in one session is not proof that the underlying service authorisation no longer permits writing. An approval dialogue is not proof that only the intended folder is readable.

Review the connection before using real work data

A concrete place to review existing GitHub access

If your approved workflow uses GitHub, the review surface depends on the integration type. For an installed GitHub App, GitHub documents a route through Settings, Applications and Installed GitHub Apps. Its configuration shows permissions and repository access. Review the installation that applies to the relevant account or organisation.

An authorised OAuth app is reviewed under the separate Authorized OAuth Apps tab. GitHub’s installed-app guide and its OAuth review guide explain these different cases. Do not assume an MCP connection always uses one particular authorisation type, or that all users can change organisation-level access.

These are documented navigation examples, not account changes performed for this article. Use the guide matching the integration you actually authorised.

Plan the exit while the purpose is clear

Assign a person to review the connection and choose a useful review point, such as completion of the three-article comparison. Remove unused configurations from the AI application and check the connected service for remaining authorisation or credentials.

Disconnecting a visible connector and revoking service-side access can be separate operations. GitHub, for example, distinguishes an app installation from authorisation to act on a user’s behalf. Follow the relevant service instructions rather than assuming one removal button covers every account.

Before revoking a shared integration, check whether other approved workflows depend on it and coordinate with its owner. Access removal should be deliberate, not an accidental interruption for the rest of the team.

Keep an access review note

Connection purpose:
AI application and publisher:
Connected service and account:
Approved data location:
Permitted records:
Account permissions granted:
Tools enabled in this session:
Where retrieved information will be processed:
Actions requiring review:
Person responsible for the connection:
Review or removal date:
Service-side access checked after removal:

Record permission names and resource boundaries, not secret tokens. The note should help someone understand why the connection exists and what to recheck later.

Try it on one existing integration

Choose a connection you already use and compare its current access with its original purpose. Identify one unanswered question about scope, tools or removal. Resolve that question with the appropriate owner before extending the workflow.