What access should an AI provider have to your systems?

Define the access boundary

“Connect your CRM” is not a sufficiently specific access request. A provider might need to read selected records, write a proposed classification or administer an integration. Those are different privileges with different consequences.

Before granting access, create a permissions matrix. Its purpose is to connect each permission to a business task and an accountable owner. The right question is not whether a provider seems trustworthy, but whether the granted access is necessary, bounded, observable and removable.

Separate people from running software

List the provider's human users separately from the identities used by the workflow. A consultant configuring an integration may need temporary setup privileges. The finished workflow may need a much narrower set indefinitely.

Record whether each connection acts through a signed-in user, a dedicated application or another supported identity. Do not assume these options have equivalent reach.

Microsoft Graph, for example, distinguishes delegated access on behalf of a signed-in user from app-only access using the application's own identity. Its documentation explains that delegated access cannot exceed what the signed-in user can access. That distinction belongs in the matrix, not only in a technical conversation. Review actual granted permissions rather than inferring their scope from a connector name.

Use one row per resource and action

Include these columns:

• Business task and internal owner.
• System, environment and resource boundary.
• Human or application identity.
• Requested permission and plain-language effect.
• Read, create, update, delete, export or administer.
• Reason the permission is necessary.
• Approval requirement and approving person.
• Start date, expiry and review date.
• Logging evidence and revocation procedure.

Record exact permission identifiers where available. “CRM access” hides too much; “read selected lead fields in the test environment” describes a reviewable boundary.

Where a connector cannot enforce the boundary you want, document that gap. A promise not to access unrelated records is not the same as a technical restriction.

Draft a scoped example

For an inquiry-classification workflow, an illustrative matrix might contain three rows.

Read: The runtime identity reads approved inquiry fields from an intake queue. It does not need billing records or unrelated attachments.

Write: The runtime identity writes a proposed category and explanation to designated fields. Deleting records and changing account ownership remain outside scope.

Configure: A named implementer configures the connection in a test environment during setup. Production changes require internal approval, and elevated access expires after the agreed setup period.

These are proposed boundaries, not claims about any listed platform's capabilities. Ask the implementer to show which controls enforce each boundary and which depend on process.

Challenge broad permissions explicitly

Microsoft's Graph permissions reference recommends requesting the least privileged permissions needed for an application to function correctly.

Apply that principle by asking what fails if a requested permission is removed. If the answer is only convenience, explore a narrower design.

Read-only access still deserves scrutiny: it can expose customer lists, internal notes or commercially sensitive files. Write access needs additional boundaries because a mistaken action can alter the source system.

Separate permission to prepare an action from permission to execute it. Drafting an email, sending it and changing the recipient list should not automatically be treated as one authorization.

Protect credentials and preserve accountability

Avoid sharing an employee's ordinary login. Prefer supported identities that your organization can manage and revoke, with individually attributable access for provider staff.

For Google Cloud workloads, Google describes service accounts as non-human identities and highlights risks including privilege escalation and information disclosure. Its guidance is specific to Google Cloud, not a universal identity design for every application.

Ask where credentials reside, who can retrieve them and what appears in logs. Protect logs too: workflow traces can contain the same sensitive information as the source records.

Approve access through evidence

Before production use, have your administrator compare the matrix with actual granted permissions. Verify an allowed operation and a prohibited operation in an authorized test environment.

Record how to stop execution, revoke access and identify affected records. Removing access does not by itself delete information already copied elsewhere; track retention and deletion separately.

Use the AI agents directory to frame capability questions, not as proof of permission controls. Keep the matrix current whenever a workflow gains a new tool, data source or action.

References and verification

Official documentation checked 2026-10-22; general access-planning guidance, not a security audit or provider certification.