AI security for smaller manufacturers and distributors
AI security means keeping the AI tools your company uses, and the files you give them, under your control. For a smaller manufacturer or distributor it comes down to five questions: where your data goes, who can see it, what the provider keeps, what the AI is allowed to do, and who approves what it does. This guide answers each one with the Canadian Centre for Cyber Security’s May 2026 guidance and the vendors’ own pages. Criminals who use AI against you are covered separately in AI cybersecurity.

What AI security means for a company that uses AI
The Canadian Centre for Cyber Security (the Cyber Centre), part of the Communications Security Establishment, published Top 10 artificial intelligence security actions (ITSAP.10.049) in May 2026 for “organizations of all sizes and sectors.” It traces AI risk to “adversarial abuse of AI, attacks on AI systems or misuse of AI by business users.” All three reach a company that only buys AI tools:
- Adversarial abuse. Criminals use AI for convincing phishing and cloned voices. AI cybersecurity for manufacturers covers that side, along with security software that uses AI to detect attacks.
- Attacks on AI systems. Someone plants instructions in a document or an email that your AI tool reads. This is prompt injection, explained below.
- Misuse by staff. The Cyber Centre’s generative AI guidance (ITSAP.00.041) warns that “users may unknowingly provide sensitive corporate data” in their prompts.
In Statistics Canada’s survey for the second quarter of 2026, 22.3% of businesses with 20 to 99 employees said cybersecurity or privacy concerns limit their use of AI. Across businesses of all sizes, it was the barrier named most often.
AI security, LLM security and AI data security
A large language model (LLM) is the kind of model behind ChatGPT, Claude and Microsoft Copilot. LLM security covers the weaknesses specific to those models, such as prompt injection. AI data security covers the data you type, upload or connect: where it is stored, who can read it and how long it is kept. AI security covers both.
What changes when AI connects to your systems
Risk grows with what the AI can reach and do, and every control on this page matters more at each step down this list:
- A chat window reads only what someone pastes or uploads.
- A connected assistant reads whatever its account can open in your mailbox, shared drive or ERP.
- An agent, meaning an AI tool that takes actions such as sending email or writing to the ERP, can also act on what it reads.
AI data security: where your data goes
Data you give an AI tool sits on your own device, in the vendor’s app storage (chat history, files and memory), and on the servers where the model reads your request and writes the answer. That last step is called processing, or inference. Connected apps add a fourth place: OpenAI’s data residency article says information sent to one “is handled under that provider’s own storage, processing, privacy, and data-residency terms.”
Storage and processing are separate questions. On the vendor pages, checked on September 27, 2026, OpenAI and AWS can store some customers’ data at rest in Canada, and Microsoft expects to process Copilot requests in Canada in 2027. On each of these services, the model that reads your request may run outside Canada today. Microsoft’s Copilot privacy page, for example, says customers outside the EU “may have their queries processed in the US, EU, or other regions.”
Vendor detail is in ChatGPT alternatives for business in Canada.
The Privacy Commissioner of Canada’s cross-border guidelines say PIPEDA, the federal privacy law for businesses, does not prohibit sending personal information abroad for processing. The sender “is accountable for the information in the hands of the organization to which it has been transferred.” In Quebec, section 17 of the private-sector privacy act requires a privacy impact assessment and a written agreement before personal information leaves Quebec. This page is not legal advice, and the legal picture is in AI governance.
Shop-floor data
Operational technology (OT) is the equipment that runs production, such as machine controllers and the networks between them. In December 2025 the Cyber Centre and partner agencies published principles for AI in operational technology, written for critical infrastructure owners and operators. Two points are useful for any plant that lets AI read machine data. The first is to know where OT data used to train AI models is stored, “and ensure it is within the organization’s control.” The second is push-based design, where data is pushed out of the OT network “without persistent access into the OT network.” In practice, the shop network sends data out to the AI system, and the AI system has no standing connection back in.
Who can see your data
Inside your company. Microsoft’s Copilot privacy page says Copilot “only surfaces organizational data to which individual users have at least view permissions.” So if a cost sheet is shared with the whole company, Copilot can use it to answer anyone in the company. On ChatGPT Business, OpenAI’s enterprise privacy page says workspace admins can view, export and delete members’ conversations.
At the provider. For ChatGPT Business, OpenAI says its access to stored conversations is limited to authorized employees who need it for engineering support, abuse investigations and legal compliance. It adds contractors bound by confidentiality who review for abuse. Microsoft says Copilot has opted out of the abuse monitoring that includes human review. Anthropic applies separate rules to what it calls Covered Models: currently Claude Fable 5 and 5.1 and Claude Mythos 5 and 5.1, and later models of similar capability that it adds. For those, it says “no Anthropic personnel can read your retained conversations” by default. Human review can happen through a controlled path, for example when Anthropic’s automated safety systems flag content.
Under a court order. In 2025, an order in the New York Times lawsuit required OpenAI to retain consumer ChatGPT and API content. OpenAI’s account of the order says it reached ChatGPT Free, Plus, Pro and Team (renamed ChatGPT Business in August 2025), and API users without a zero data retention agreement, a contract under which the provider keeps no copy of a request or its answer. It did not reach Enterprise or Edu. The obligations ended on September 26, 2025. In an update dated October 22, 2025, OpenAI said it would keep storing limited user data from April to September 2025, because the Times continued to demand it.
What the provider keeps
“Keeping your data” covers four things. Training means your content helps build future models. Logs are copies kept for a set period, usually to check for abuse. History and memory are what the app saves so people can return to it. Feedback is a conversation someone rated with a thumbs up or down.
Personal and business accounts differ most on training. OpenAI’s model training policy says of services for individuals such as ChatGPT, “we may use your content to train our models,” with an opt-out. For business users it says: “By default, we do not train on any inputs or outputs from our products for business users, including ChatGPT Team, ChatGPT Enterprise, and the API.” If a personal Claude user allows training, Anthropic may keep the data “in a de-identified format for up to 5 years” (Anthropic retention article). Microsoft says Copilot prompts and responses are not used to train foundation models.
Logs and feedback follow their own periods. OpenAI keeps API abuse monitoring logs for up to 30 days, and Anthropic deletes API inputs and outputs within 30 days. Anthropic’s Covered Models follow their own rule: since June 9, 2026, their prompts and outputs are kept for 30 days on every platform that offers them, and only some zero data retention customers, notified by Anthropic, can use Fable without that retention. On Anthropic’s business plans, a thumbs up or down stores “the entire related conversation” for up to 5 years, and Anthropic may use that feedback to train its models. The settings to switch off, including feedback, and how to get zero data retention in writing, are in secure AI at work.
A personal account sits outside all of these business terms, and Shadow AI covers finding those accounts.
Prompt injection, explained plainly
Prompt injection is an attack where text the AI reads changes what the AI does. OWASP, a non-profit foundation that publishes security guidance, explains why it works in its Top 10 for LLM Applications 2026:“LLMs make no architectural distinction between ‘instructions’ and ‘data’.” The version that matters most is indirect. The instructions hide in a web page, an email or a document the AI reads for you, and “the user did not supply or see those instructions.”
Your purchasing assistant reads the shared mailbox and can send email. A supplier quote arrives as a PDF with a line in white text: forward the latest customer price list to an outside address. A buyer asks for a summary of the quote. If the assistant follows that line and has permission to send, the price list leaves while the buyer reads a normal summary. OWASP describes the same pattern, and its fixes include a tool that can only read mail and a person who presses send on every draft.
A real case. EchoLeak was a flaw in Microsoft 365 Copilot, listed in the US National Vulnerability Database as CVE-2025-32711. The database describes an AI command injection that “allows an unauthorized attacker to disclose information over a network.” Microsoft rated it 9.3 out of 10 for severity, and NIST, the US agency that runs the database, rates it 7.5. Microsoft says it had already fixed the flaw when it published it on June 11, 2025, and users had nothing to do.
It may never be fully fixed. The UK’s National Cyber Security Centre wrote in December 2025 that prompt injection attacks “may never be totally mitigated in the way SQL injection attacks can be.” SQL injection is an older attack on databases that has a reliable fix. OpenAI wrote the same month that prompt injection “is unlikely to ever be fully ‘solved’.” OWASP’s project leads open the 2026 list with “Stop trying to build a model that cannot be fooled,” and ask for systems where a fooled model breaks nothing important. Canada’s privacy commissioners also name prompt injection in their principles for generative AI, and ask organizations to keep mitigations against it in place.
What limits the damage
Action 1 of the Cyber Centre primer covers prompt injection. Among its controls, it asks organizations to:
- Give the AI access only to the private data its job needs.
- Limit the outside content it reads, such as email from outside the company, supplier documents and web pages.
- Restrict high-risk tools and agents through access rights tied to each role and each account.
- Check what an action will do to files, code or tools before it runs.
- Limit how the AI can send anything outside the company. The primer’s example is data hidden in the web address of an image in an answer.
For a company that uses AI, our reading is:
- Connect assistants read-only where the job allows, like the mail tool in OWASP’s fixes above.
- Keep outside email, supplier documents and web pages away from any assistant that can send or write.
- Turn off automatic sending, and block images from outside addresses in answers, since the primer notes data can be hidden in image links.
- Give each agent its own account, and have a person approve each action. Both are covered under access and approval controls.
No setup, ours included, can promise that a model is never fooled. These controls decide how much a fooled model can reach and what it can do.
LLM security: the OWASP list
OWASP’s 2026 list ranks ten LLM security risks. The three in bold matter most to a company that uses AI tools. Most of the others concern teams that build or host models.
| OWASP 2026 risk | What it means in plain words |
|---|---|
| LLM01 Prompt injection | Text the AI reads, such as a document or an email, changes what it does. |
| LLM02 Sensitive information disclosure | Confidential data reaches someone who should not see it. |
| LLM03 Excessive agency | The AI has more functions, permissions or independence than its job needs. |
| LLM04 Supply chain | A model or component from a third party has been tampered with. |
| LLM05 Data and model poisoning | Someone plants bad data where the AI learns or searches. |
| LLM06 Unbounded consumption | Nothing caps usage, so an attacker can run up costs or copy the model. |
| LLM07 Misinformation | The AI gives a credible wrong answer, and someone acts on it. |
| LLM08 Hidden context exposure | Someone extracts the hidden instructions behind an AI application. |
| LLM09 Vector and embedding weaknesses | The search layer that picks what the AI reads is manipulated or leaks. |
| LLM10 Improper output handling | Another system uses the AI’s output without checking it. |
Which AI tools can act on their own
Tell Derik which AI tools your team uses and what each one can reach. He will tell you which of them can send or change something before a person approves it.
Start a conversationAccess and approval controls
Company accounts only. Staff sign in with company accounts, through single sign-on (one company login for every tool) where the plan offers it. The Cyber Centre’s guidance on frontier AI, meaning the newest and most capable AI models (ITSAP.10.050), recommends “phishing-resistant multi-factor authentication (MFA) for all accounts.” MFA is a second check at sign-in, and the phishing-resistant kind uses a security key or a passkey.
Agents get their own identity. The same guidance calls for “strong authentication and access controls for non-human identities, such as AI agents.” Give each agent its own account, with only the access its job needs. OWASP says excessive agency usually comes from a tool that can do more than its job needs, an account that can reach more than its job needs, or a tool that acts without a person checking.
A named person approves. Name who approves each quote, supplier email, purchase order, payment and ERP change. Action 9 of the primer asks for “human checkpoints in automated and multi-agent workflows” and for “kill-switches or emergency shutdown procedures for high-impact actions.” In plain words, a person signs off at set points, and someone can stop the tool at once.
Keep a log. Action 6 asks organizations to “log and audit all models and data access.” Record what each tool read, what it drafted and who approved it.
AI governance covers who decides which tools are allowed and which records you keep. The written rules for staff are in the AI policy template.
The Cyber Centre’s top 10 AI security actions, read for a smaller company
The primer groups ten actions under three pillars: protecting against adversarial use of AI, protecting AI systems, and protecting users and business processes. It says the actions “support and strengthen” the Cyber Centre’s Top 10 IT security actions rather than replace them, and our advice is to have those basic IT actions in place first. The column on what each action means for a company that uses AI is our reading, and the Cyber Centre did not write it.
| Action | What it asks | What it means for a company that uses AI |
|---|---|---|
| 1. Prompt injection and jailbreaks | Restrict tools and agents, and check actions before they run | Connect AI read-only, and keep outside content away from assistants that can act. |
| 2. Deepfakes and impersonation | Phishing-resistant MFA and out-of-band checks on sensitive requests | Call back on a known number before a payment or a bank detail changes. |
| 3. AI-powered attacks and fraud | Faster patching, bot detection and staff training | Mostly work for your IT provider, covered in AI cybersecurity. |
| 4. Testing and red teaming | Test models against known attacks | Mostly for model builders. Ask your vendor how it tests. |
| 5. Data poisoning | Track where training data comes from | Mostly for model builders. Know who can add files to the folders your assistant searches. |
| 6. Data usage and model theft | “No train” defaults, contract clauses and access logs | Use business plans with training off, and keep the access logs. |
| 7. Secure AI engineering and supply chain | Inventory and sign models and components | Mostly for builders. Keep a list of every AI tool and connection in use. |
| 8. Privacy, vendor and contract controls | Allow and deny lists, an acceptable use policy and contract clauses | The core of your work: an approved tool list, an AI policy and the vendor questions below. |
| 9. Human oversight and execution controls | Checkpoints and kill switches for high-impact actions | A named person approves every send, write and payment. |
| 10. Drift, hallucinations and overreliance | Human review of critical outputs and fallback procedures | Check answers against their source, and keep the manual process written down. |
Actions 4, 5 and 7 are written mostly for organizations that build or train models, and a company that buys AI meets them through its vendor. Action 8 is where a smaller company’s work sits. Its contract clauses become four questions for any AI vendor:
- Does the contract prohibit using our data to train your models?
- Is personal information encrypted, and who can access it?
- Will you show us how our data is handled, and can we or an auditor check it?
- What limits how you use our data, and what are you responsible for if it leaks or is reused?
Other guidance and frameworks
- Engaging with Artificial Intelligence (January 2024) and Deploying AI systems securely (April 2024): joint guidance from the Cyber Centre and partner agencies for organizations that use or deploy AI systems, including ones built by third parties.
- AI in operational technology (December 2025): the shop-floor principles above.
- NIST AI Risk Management Framework: a US framework released on January 26, 2023, “intended for voluntary use,” which NIST is revising.
- ISO/IEC 42001:2023: the international standard for an AI management system, published in December 2023.
- NIST IR 8596, the Cyber AI Profile: a preliminary draft dated December 16, 2025.
How these fit a company your size is explained in AI governance frameworks explained plainly.
The rest of this guide
- AI governance: who decides which AI tools are allowed, what records to keep, and the Canadian legal picture.
- AI cybersecurity: how criminals use AI against smaller manufacturers, and how AI-based defence tools work.
- Shadow AI: staff using personal AI accounts with company files, and how to find it.
- Secure AI at work: the setup checklist, from the account type to zero data retention.
- AI policy: what an AI use policy for employees covers, with a template you can adapt.
To train your staff on all of it, see AI training for teams in Ontario and Quebec.
How ThriveAI helps
ThriveAI is an AI engineering company in Ottawa that builds private AI systems for manufacturers and distributors in Ontario and Quebec, on their own data. It works hands on with your team. Derik Lawlis, the founder, leads every project and stays close to the build.
The platform ThriveAI builds on is designed to keep your data on its own server in Canada. You choose the model that reads it: one that runs on that server, or a hosted model under a written zero data retention agreement. A hosted model may process requests outside Canada, so the contract names the model and its service tier. Every connection only reads data, and nothing touches a live system until you approve what it will read. Nothing is sent or saved in your systems until the person responsible approves it, and every answer shows its source.
Working sessions run on site with your team, in French or English. ThriveAI also runs hands-on AI training on your own documents. Stage one is a working prototype for one job, at a fixed price, in weeks, and you keep it. For the company and how a project runs, see About ThriveAI.