When an AI upgrade changes your business risk

A small change in software can change who has authority

Your team has approved an AI assistant to answer product questions. A supplier now offers a connection to the order system, allowing employees to check delivery status in the same conversation.

The benefit is easy to understand: fewer systems to navigate and quicker answers for customers. But during setup, the team discovers that the proposed connection can also change delivery addresses.

In this hypothetical distributor, a feature intended to save time could also redirect a shipment. The supplier’s name has not changed. The software still looks familiar. The authority being granted is materially different.

Our view is that AI approval should follow what the system can access and do. A familiar product name should not carry an old approval into a new business activity.

Understand the change before deciding how much review it needs

A connector is the link between an AI application and another system, such as an order platform or document collection. It allows the application to request information or perform supported actions. The functions enabled and the permissions granted determine its reach.

A supplier announcing a feature does not mean your organization has enabled it. Equally, telling an assistant to use a connection only for lookups does not establish that its account lacks permission to edit records. Leaders need a clear account of the configuration their team will actually use.

OWASP distinguishes unnecessary functions, excessive permissions and excessive autonomy in its guidance on AI systems.^[1] The business implication is straightforward: access should match the service you want to deliver.

That includes confidentiality. An assistant with read-only access may still reveal another customer’s order if it can retrieve records beyond the employee’s scope. Editing rights are only one part of the decision.

Keep the benefit while narrowing the authority

For the distributor, the business requirement is to answer delivery-status questions for assigned orders. Address changes and bulk customer exports are outside that requirement. The team can ask whether the connector supports the narrower use before deciding whether to activate it.

This avoids treating adoption as an all-or-nothing choice. The organization may be able to obtain the convenience it wants while keeping consequential changes in the established order-management process.

If a supplier cannot support the required restriction, that is useful information for procurement. The alternatives are to hold the connection, use a different integration or explicitly reassess the proposed business process. Broad access should not become an accidental condition of a small productivity improvement.

Security review should also remain proportionate. A change in screen wording deserves different attention from permission to send customer messages or alter banking details. A short set of review triggers can make meaningful changes visible without forcing every update through the same process.

Three questions before you enable the feature

1. What business outcome are we approving? Write a short statement of the permitted task, information and users. For this example: employees can view delivery status for their assigned orders. Name the owner who can decide whether an expansion is justified.
2. What has changed in access or authority? Ask the technical owner or provider to compare the previous and proposed configuration. Include new records, edit or send functions, external destinations and work that can proceed without a person’s involvement.
3. What evidence supports the boundary? Request a demonstration of an allowed lookup, a prohibited change and access to an unassigned synthetic record. The team should show what the receiving system allowed or denied, as well as what the assistant said.

The Canadian Centre for Cyber Security recommends understanding tool scope and avoiding overly broad access in agentic systems.^[2] The tests above are a practical way to turn that principle into an activation decision for a specific connection.

Make the decision easy to revisit

Record the approved use, accountable owner, enabled connections and supporting review in your AI solutions registry or existing technology register. Link to detailed configuration evidence rather than copying credentials or sensitive data into the register.

A useful decision is specific: permit status lookups for assigned orders after the required tests pass; keep address changes disabled; review again if the connector’s functions or permissions expand. Also identify who receives vendor notices and who can suspend the connection.

That record helps the next reviewer understand what the organization actually accepted. It gives operations, technology and procurement a shared starting point when another useful feature arrives.

Does your AI approval describe the product you bought, or the authority you have agreed to give it?