What should an AI integration be allowed to see and change?

Scope the credential, not just the code

Careful code with a full-access key is one bad loop away from a large cleanup. The credential is the real boundary, because it is the thing that holds even when the logic is wrong.

Start from the workflow. List the objects it reads, the fields it writes, and nothing else. If the platform supports field-level permissions, use them; if it only supports object-level, at least separate read-only credentials from write credentials so the analysis path cannot modify anything.

This is ordinary practice in software engineering, and it gets skipped for AI tools because they arrive as products rather than as code. Installing a connector through a settings screen does not change what it can reach inside your connected systems.

A short inventory worth doing once a year

• Which credentials exist for each connected system, and what each one is for.
• What scope each has, stated as objects and permissions rather than as a plan name.
• Who can rotate it, and whether rotation has ever actually been tested.
• What happens when the creating employee leaves. Integrations authenticated as a departing person's account break on their last day, often silently.
• Which integrations are still running that nobody uses any more. These are pure risk with no benefit.

Data that leaves your systems

Separate from access scope is the question of what content is sent to a model provider, what that provider retains, and for how long. Those settings exist and are worth reading rather than assuming.

Obligations around customer data, call recordings and consent vary by state, by industry and by contract, and they change. Treat the specifics as a question for your own counsel. The engineering side, which is limiting what gets transmitted and configuring retention deliberately, is the part we can settle in the integration design.

Give automation its own identity

An automation should authenticate as its own service account, never as a manager's login. Two reasons: the audit trail becomes readable, because you can tell automated changes from human ones at a glance, and access can be revoked without disrupting a person.

This one decision makes the difference between an audit that answers questions and one that produces a list of changes attributed to somebody who was on vacation. It costs nothing at setup and cannot be retrofitted onto history.