When a promo email landed in my inbox promising great productivity gains by connecting ChatGPT with some recognizable, brand name tools, I was briefly intrigued. There is something reassuring about a screen full of familiar logos. Dropbox, Slack, HubSpot, Stripe, Docusign, PayPal, Canva and the rest all look like things that could benefit from AI automation, particularly if they promise to make AI less sketchy and more like popular productivity tools.
What caught my eye was that little 'plus' sign next to them. Call me old-fashioned, but I think a new business relationship should take more than just one click. Is there a real need to make it that easy?
In effect, the plus sign looks like a feature toggle, but in these cases it is closer to a vendor authorization, and to me, as a security guy, that sounds like consent and accountability risk. Looking deeper into it and depending on the integration, you may be allowing an AI assistant to search corporate files, read conversations, retrieve customer records, inspect financial information, or create and change records in another service. OpenAI describes these connections as apps within plugins, and some support write actions that can create or update information outside ChatGPT.
The practicality of this is easy to understand. As always, users want convenience, employers expect productivity, software vendors want deeper integration (for reasons), and AI providers want assistants that can do useful work, because that's what they've been promising the world. So they get the benefits up front, and the risk is accepted by the user.
You may not see the cost of excessive permissions, foreign processing, an access control flaw, unknown or weak deletion practices, or a compromised service account until much later. Or you never think about it again.
I'm not making an argument against plugins. This is an argument for treating them like the business integrations they actually are. Any company that doesn't conduct a full Vendor Risk Assessment on every plug in within the enterprise is running the risk of a false sense of security.
Can AI reach into your systems?
Traditional software integrations are usually straightforward as they pass specific cells of data to and fro according to defined rules. AI integrations add a reasoning layer between the user and the application, which is useful because the assistant can interpret natural language and decide what information or action is relevant.
That same flexibility also changes how risk should be considered by both individual users and companies.
Connecting an "assistant" does more than just add a feature. It can give the AI access to the same corporate systems, records and data available to the employee who authorized it. If that person can see years of Slack history, thousands of Dropbox files, an entire CRM pipeline, or sensitive project records, the assistant may have access to a far larger information surface than the user realizes. The security question is no longer only whether the application account is secure. It is also whether the AI should be allowed to exercise that account’s authority.
Naturally, the consequences vary by application. Slack, Dropbox, HubSpot, ClickUp and HoneyBook can create a large information blast radius because they contain institutional memory. Stripe, PayPal and Mercury can expose financial information. Docusign can involve legally significant agreements. Shopify and Wix can affect customer-facing systems, while Canva and Figma can contain confidential campaigns and unreleased product information. These distinctions emerged clearly in the earlier vendor-by-vendor assessment.
The important point is that “read only” does not automatically mean “low risk.” Reading a harmless marketing image is low risk but reading every customer file in a repository is anything but.
The issue with cross-system leakage or data collection by these "big data" systems (yes, I said it) is compounded by such exploits as prompt injection, weak access controls and a lack of monitoring, because after all, the 'assistant' is the user, so it is expected to act with the same authority as that privileged user.
That is the fundamental issue with risk modeling in the age of AI, progress towards AGI and concerns over the coming ASI "apocalypse". A fundamental failure to remember basic security practices related to strict controls over the agent as a privileged user, separate from the human user. Blurring that line will lead to all kinds of nonsense, spectacular "escapes" as we have seen over the past few weeks, and a general sense that any FUD (fear, uncertainty and doubt) will be okay to print because after all, anything is now possible with 'frontier AI', right?
Canada adds another layer of accountability
Our own Canadian privacy law does not generally say that all personal information must stay physically inside Canada, but it does place responsibility on the organization that controls the information.
The Office of the Privacy Commissioner of Canada (OPC) reminds everyone that organizations remain responsible for personal information transferred to third parties for processing and should ensure comparable protection through contractual or other means. And claiming ignorance is not a defense.
On September 10, 2026, the OPC issued new guidance specifically telling organizations to assess third-party service providers before adoption including their privacy practices, processing arrangements, contractual protections and accountability measures.
That guidance is almost tailor-made for AI plugins and that's what caught my eye today.
Any Canadian company should know what personal information can (and usually will) flow through, where it is processed and by whom, how it is monetized (because let's face it, it will be), and what happens if/when there is a breach.
The mere mention of how the data is deleted is a bit of a joke at this point, since secure disposal across borders and layers of a complex big data structure is only likely to be performative. However, the way it's handled and documented may still provide predictive information for future leaks and breaches.
So before approving an AI integration, we should all be asking companies about data access, location, processors, retention and breach response when it comes to their suppliers and integration partners, and their dependencies across the full supply chain. Don't have visibility all the way down? That should be a hint that you're accepting a whole lotta risk.
Take data residency for instance. OpenAI supports Canadian storage-at-rest residency for certain eligible offerings, but its documentation says that information handled by external apps and MCP services is subject to the external provider’s own storage, processing and residency terms. A Canadian residency setting in one part of the stack does not make the entire integration Canadian, or compliant with Canadian law.
The right question, therefore, is not “Is this plugin allowed in Canada?” The right question is “Can we demonstrate that this specific use of this specific integration meets our legal, contractual and security obligations?”
What I look for before approving one
When I run cybersecurity audits and Verify™ risk assessments for Datarisk Canada, I don't just blindly take a SOC 2 report, an ISO certificate, a penetration test or a privacy policy as final evidence of commitment to customer data protection. I look at the entire intent of the service, legal entity, infrastructure and integration being evaluated. This risk-assessment methodology is so simple as to be able to be conducted by individuals, let alone entire Procurement departments.
My practical due-diligence process comes down to these five things:
- Map the data and permissions before judging the vendor. Identify what the integration can read, what it can change, which user account it inherits, what historical information it can reach, what countries are involved, and which subprocessors are in the chain. The objective is to understand the maximum plausible impact before deciding whether the convenience is worth it.
- Verify the evidence, not the badge. If the vendor claims SOC 2 Type II assurance, ask for the current report and confirm the legal entity, system scope, audit period, exceptions, subservice organizations and customer controls. If ISO/IEC 27001 is claimed, verify the actual certificate, scope, certification body and validity. A certification can be perfectly genuine while still excluding the new AI connector you actually care about.
- Assess the AI integration itself. Ask whether the plugin, app, API or MCP endpoint was included in the audit scope, whether it has been independently penetration tested, how OAuth tokens are protected and revoked, whether cross-tenant authorization was tested, whether write actions can be disabled, and whether logs can show what the assistant accessed or changed.
- Read the privacy and contract terms with the same care as the security report. Determine whether the vendor acts as your processor or as an independent controller, whether data may be used for analytics, product improvement or AI training, how long it is retained, how deletion is verified, which subprocessors receive it, and how quickly the vendor must assist after an incident. SOC 2 and ISO 27001 are evidence of controls. They are not legal opinions that your deployment complies with Canadian privacy law.
- Reduce authority before relying on good behaviour. Use dedicated accounts where practical, narrow permissions, restricted folders and channels, strong MFA, role-based access, approval for consequential actions, and human review for financial, legal and public-facing changes. OpenAI provides administrative controls that can restrict available read and write actions and determine when users must approve them, but those controls have to be configured deliberately.
These checks take a bit of time, but you'll always learn from the process. Trust me.
What if you already connected one?
To put it clearly, connecting an apps that share data definitely does not automatically mean a breach occurred, but it does mean you should find out what you authorized.
Before allowing all users access to AI chatbots, check whether the integration had access to sensitive corporate information, ask your IT, security or privacy team to determine what information could have been reached and whether the available logs show unusual retrieval or changes.
If personal information, privileged material, confidential client records or financial data may have been disclosed to an unauthorized party, treat that as a potential incident and use the organization’s normal breach-response process. The vendor should also be able to explain retention, deletion, subprocessors, security contacts and breach-notification procedures.
Is it about ChatGPT, Gemini or CoPilot?
Kinda. Many vendors are making their integrations portable across AI environments through MCP and related technobabble, which means this is becoming an organization-wide AI governance problem rather than a ChatGPT-specific one. The earlier review found multiple examples of the same business services being exposed to ChatGPT, Claude and other MCP-capable clients.
A policy that simply says “we do not allow this in ChatGPT” is meaningless if an employee can connect the same corporate account to another AI. It's important to keep in mind that these AI integrations are going to become normal because they are genuinely useful. It would be a mistake to normalize them before understanding what they can see, what they can do, where sensitive information goes, and most importantly, who will be accountable when something fails.
Whether you're a user or an IT department, the little plus sign should be the the trigger for a risk assessment.
