Reviewing AI connector changes

A new connector deserves a new security decision

A connector links an AI application to another system, such as a document repository, customer database or order platform. Its functions and the access granted to its account help determine what the AI can retrieve, change or send.

Distinguish three things: what the supplier offers, what your team enables and what the connected account is actually permitted to do. An announcement alone does not establish your exposure. Review the configuration used by your organization.

The Canadian Centre for Cyber Security highlights privilege scope creep and recommends understanding a tool’s scope, including the external effects it can trigger, before incorporating it into an agentic system.^[1] A practical application is to compare the proposed connection with the use your organization already approved.

How a request becomes an action

Imagine an employee asking, “Where is order 1047?” The model can interpret the question, but a separate connection is needed to obtain the current order record. A typical sequence looks like this:

1. The employee makes a request. The application identifies the employee and the business task they are allowed to perform.
2. The agent selects a tool. A tool is a function it can request, such as looking up an order. The agent supplies a target, here order 1047, and the information the function needs.
3. The connector carries the request. It authenticates to the order system using an identity: either the employee’s delegated identity or an account used by the application. A credential is the secret or token used to prove that identity.
4. The receiving service checks permission. It should establish whether this caller may perform this operation on this record. A valid identity alone does not establish that permission.
5. The service returns a result. The assistant presents the status. The receiving system’s records help establish which operation actually happened.

The risk appears when these steps disagree. The employee wants a lookup, but the connector exposes an address-update function and its account is allowed to use it. A mistaken or manipulated request could then become a real change.

Permission and approval are different. Permission defines what an identity may do. Approval is a decision authorizing a particular change or transaction. Approving installation of the connector does not approve every future shipment change. A prompt saying “do not edit orders” also does not remove the account’s edit permission.

1. Recognize changes that need another review

Use a short set of triggers within your existing change process. The table below is a recommended starting point. Adapt it to the sensitivity of the information and the consequences of an unauthorized action.

NCSC’s guidance recommends update testing that accounts for behavioural changes caused by changes to data, models or prompts.^[3] Reuse relevant tests rather than restarting every assessment from a blank page.

Keep the process proportionate. A wording change on a screen and permission to export customer records deserve different attention. Continue applying security fixes through your established patching process.

2. Compare the business need with the proposed access

Hypothetical example: a distributor uses an AI assistant to answer employees’ questions from product manuals. A new order-system connector would let employees check delivery status without switching applications.

During setup, the team finds that the proposed account also permits delivery-address changes. That capability could redirect a shipment. It requires a different decision from looking up its status.

Ask whether the supplier can support that narrower configuration. If it cannot, keep the connector disabled while considering another integration or a revised use case. A useful feature does not settle the question of acceptable access.

What the technical reviewer should demonstrate

For this lookup-only use case, examine three layers together: the functions exposed to the agent, the connected account’s rights, and the rule limiting which orders each employee may see. Removing the update function reduces the available actions; removing write permission adds an independent restriction.

If the connector uses one shared account, ask how the order service or another trusted enforcement component receives and validates the employee’s identity. The model must not be able to choose a different employee identifier and gain their access. If all requests appear as the same unrestricted account, the employee-level boundary has not been demonstrated.

Read-only access still needs record-level restrictions: the assistant could disclose another customer’s order without editing it. Also identify which order details leave the order system, which provider processes them, and whether responses are saved in conversation history or logs. Limit returned fields to the task’s needs.

OWASP’s Excessive Agency guidance distinguishes unnecessary tool functions, excessive permissions and excessive autonomy. It recommends enforcing authorization in downstream systems.^[2] Telling an assistant to “only check status” does not remove write access from its account.

3. Test permitted work and prohibited actions

Use synthetic records and a non-production environment. Record the connector version, acting identity, effective permissions and expected outcome before each test. For the distributor, begin with:

1. An allowed lookup. An employee requests status for an assigned test order. Verify the returned record and that no update occurred.
2. A prohibited write. Attempt an address update through the connection. Verify that the receiving service rejects it and the record remains unchanged.
3. An instruction embedded in retrieved data. Put a request to change an address into a test order note. Observe whether the agent attempts the action and whether the receiving control blocks any attempt.
4. A record outside the user’s scope. Request an unrelated test order. Verify that the connection does not disclose its information.

A model declining an instruction and an access control denying an attempted operation are different observations. Record which occurred. Where no tool action was attempted, that run alone does not demonstrate that the permission control would block it.

Reconcile the agent’s output with records from the receiving system. An unavailable audit record is an evidence gap. Passing these tests supports a bounded decision about the tested configuration; it cannot establish that every future attack will fail.

Use the companion workbook’s seven fields to connect the requested task to the actual action, target, permission, approval, execution result and finding. Include a test identifier and evidence reference in each record, while keeping sensitive traces in a controlled location.

Turn test observations into a decision

Define a successful outcome before testing. For the distributor, the approved boundary is: employees can read status for assigned orders; they cannot edit addresses, export the order database or read unrelated orders. Use two test employees with different assignments, and verify that the test permissions match the configuration proposed for production.

Keep the requested operation, identity, target, service response and before-and-after record together using a common test ID. A screenshot of a settings page helps describe the configuration. It does not establish that a receiving service enforced it.

Use three result categories: demonstrated when the expected outcome has supporting evidence; failed when the outcome breaches the defined boundary; and not demonstrated when evidence is missing or the relevant path was never exercised. Record a finding separately from the operation’s success or denial.

In the workbook’s hypothetical example, the decision is to hold activation while T03 is investigated and relevant tests are repeated. A blocked attack does not automatically make the final access control a failure. The remaining question is whether the agent can be redirected toward another available action that lacks equivalent protection.

Make ownership and activation explicit

Name a business owner to define the permitted use and a technical reviewer to validate the configuration. A small organization may assign both roles to the same person, with additional review where the consequences warrant it.

Ask the supplier how it communicates changes to connector functions, permissions and data handling. Establish who receives those notices, how they are assessed and what options exist to defer a new capability. If advance notice is unavailable, document that limitation and the controls available to detect or restrict changes.

Record one decision: enable the reviewed scope, hold pending specified evidence or controls, or decline the proposed connection. Assign an owner and due date to unresolved findings. A conditional decision should state what must be completed before activation.

A useful decision could read: “Hold the connector. The technical owner will remove unnecessary functions, investigate T03 and provide repeat-test evidence. The operations owner will authorize lookup-only access for assigned orders once those conditions are met. Address changes remain outside the approved use.” Replace those roles with named people and dates in the actual record.

If your supplier operates the controls, request a demonstration for your configuration, the resulting service records and a clear explanation of any evidence it cannot provide. Treat unavailable evidence as a limitation in the approval decision. After activation, compare the deployed permissions with the reviewed version and monitor denied operations and unexpected access changes.

Also confirm how the capability can be suspended if testing or operation reveals a problem. The related guide on stopping an AI agent safely addresses that operational question.

Keep the AI solutions registry connected to real use

An enterprise AI solutions registry is useful when it supports decisions about systems people actually use. Record the business purpose, accountable owner, vendor, model and architecture. Add enabled connectors, permitted actions, data destinations, acting identities and the date and evidence of the latest review.

Keep permissions described at a useful level and link to the authoritative configuration. Do not copy credentials, personal data or sensitive prompts into a general-access register. Protect the detailed evidence separately.

For each change, retain the previous scope, the reviewed scope and the decision. This gives the next reviewer a starting point and helps leaders identify where similar connections could reuse established controls.