AI security in Canada, for the models you already run

Trusted by

  • Broadcom
  • SSENSE
  • Mondou
  • Western University
  • Votatec
  • Ren's Pets
  • City of Mississauga
The work

AI security, three pillars, one operator.

One Canadian team attacks your AI, then hardens it.

  1. AI threat modelling

    We map what your model reaches, who can reach it, which tools it holds, and what an attacker gains. Data flows, not diagrams.

  2. AI red teaming

    Prompt injection, data extraction, and jailbreaks run against your actual deployment, under written rules of engagement.

  3. Securing AI workloads

    Gateways, output filtering, retrieval permissions, and tool authorisation built into the pipeline instead of written into a document.

By industry

Does AI Security work the same way in every industry?

No. The AI Security work is the same craft in every sector, but the conditions around it are not. In financial services that means OSFI's technology and cyber risk rules; in government, Protected A, B and C data handling; and in defence and aerospace, controlled goods rules, CMMC and the flow-down from your prime. We keep the service and change the part that bends.

  • OSFI's technology and cyber risk rules set what an examiner will ask to see.

    OSFI B-13. Technology and cyber risk across three domains: governance, technology operations and resilience, and cyber security. It binds federally regulated institutions, and only those.

    • OSFI B-10
    • OSFI E-23
    • Provincial credit union regimes
    Financial services IT
  • Protected A, B and C data handling decides where the work can run and who can touch it.

    Protected A, B and C. Each level changes where the data can physically live, who can reach it, and what you have to prove about both. Most files turn on Protected B, and most disagreements turn on what counts as reaching it.

    • ITSG-33, and ITSP.10.033
    • CPCSC
    • PIPEDA and the Privacy Act
    Government IT services
  • Controlled goods rules, CMMC and the flow-down from your prime set what a supplier can do.

    ITAR and the Controlled Goods Program. Registration under the Defence Production Act is mandatory before anyone examines, possesses or transfers controlled goods in Canada. Technical data counts, so a drawing sitting on a laptop is in scope.

    • CMMC
    • NIST SP 800-171
    • CPCSC
    Defence and aerospace IT
  • Health information sits under provincial privacy law, and your IT provider is usually the custodian's agent.

    PHIPA. Ontario's health privacy act, with its own definition of a custodian and its own duties for the agents acting on a custodian's behalf. Your IT provider is usually an agent.

    • Provincial equivalents
    • PIPEDA
    • Breach notification
    Healthcare IT
  • Solicitor-client privilege decides how a firm can handle its data.

    Law Society obligations. Confidentiality and competence duties reach the technology you practise with, and the vendors who touch client information. The firm is expected to have assessed the provider, which means the provider should arrive with the answers.

    • Solicitor-client privilege
    • PIPEDA breach notification
    • Quebec Law 25
    Legal IT services
Request a consult

What do you need from AI Security?

Tell us who you are and what you're working on. A senior engineer reads your message before replying, so the first answer is a real read on scope, risk and timing, within an hour, 24/7. Nothing here is a commitment, and we'll tell you plainly if we're not the right fit.

I agree to receive emails from SMEnode.

We use your details to reply to this message. You can unsubscribe from our emails at any time. Privacy

Your request

Service
AI Security

What happens next

  1. A senior engineer replies within an hour, 24/7, never an SDR.
  2. We book a 30-minute call to listen, sketch options, and flag risks.
  3. You get a scoped statement of work within 3 business days.

Call the 24/7 line

+1 514-465-1584
The deep dive

Securing AI in Canada, made real.

Two different services share this name. We do the one that defends your models.

Two services share this name, and we do the second one.

AI security splits in half and buyers get sold the wrong half constantly. One meaning is using AI to defend a network: threat detection, alert triage, the products every vendor now ships. The other is protecting the AI systems you run from being attacked, and that's ours. Model security, pipeline security, and the retrieval layer where most real incidents actually happen. If a vendor answers "how do you secure our assistant" by describing their detection engine, they've heard a different question from the one you asked.

Where prompt injection risk actually sits.

Prompt injection is the risk that earns its reputation. It sits at LLM01 on the OWASP list because it unlocks most of the others, and it isn't fixed by a better system prompt. Risk clusters in three places. Retrieval that returns documents the asking user shouldn't see, which is a permissions failure wearing an AI costume. Output that leaves without inspection, so extraction succeeds quietly. And an agent with tool access, where a successful injection stops being a disclosure and becomes an action. We test all three by attempting them.

The Canadian rules and guidance that actually bind you.

There is no Canadian AI statute to comply with. AIDA died when Parliament was prorogued in January 2025 and no successor has been tabled, so what binds you is privacy law, your sector regulator, and your client contracts. The guidance, though, is unusually good: the Canadian Centre for Cyber Security published Top 10 AI security actions (ITSAP.10.049) in May 2026, structured on three pillars covering adversarial use of AI, protecting AI systems, and protecting users and business processes. OSFI has issued its own frontier AI bulletin for financial institutions. PIPEDA applies to whatever your model can reach, and a breach here averages 7.11 million dollars in Canada.

Want a Senior IT Consultant's Read on Your Setup?

Tell us what you run today and what keeps breaking. A senior SMEnode engineer replies within an hour with a first read on scope, risk and timing. No sales handoff.

Request a consult
The method

How our model security work runs.

Four steps, and the second one is us attacking your system on purpose. Reviewing an architecture diagram tells you what should happen. Running the attack tells you what does. We work against a real deployment with agreed scope and written rules of engagement, because a red team on production needs both. Findings arrive with the exact prompt or request that worked, so your engineers can reproduce them without taking our word for anything.

Engagement phases

Phases 01 to 04

  1. Model the threat

    What the model reaches, who can reach it, what tools it holds, and what an attacker gains. Data flows, not diagrams.

  2. Attack it

    Prompt injection, indirect injection through retrieved content, extraction, jailbreaks, and tool abuse. Scoped and logged.

  3. Harden the pipeline

    Retrieval permissions, output filtering, gateway controls, tool authorisation. Fixes in the pipeline, not guidance in a document.

  4. Retest and hand over

    Second pass against the fixes, then the test set goes to your team so regressions get caught later.

Questions

AI security questions, answered straight.

Answers first, including which half of this market we're in. An architect takes the call.

Securing your AI. We test and harden the models, pipelines, and retrieval you run. Using AI to detect network threats is a different service and mostly a product purchase; our managed security practice covers that side. Buyers get these confused constantly because vendors use one phrase for both, so it's the first thing we establish on a call.

Not eliminated, and anyone claiming otherwise is selling. It's mitigated in layers: retrieval that respects the asking user's permissions, output inspection before anything leaves, tool authorisation so a successful injection can't act, and least privilege on everything the model touches. We test each layer by attacking it. The goal is making a successful injection worth very little.

Attempted attacks against your real deployment under written rules of engagement. Direct and indirect prompt injection, data extraction, jailbreaks, and tool abuse where agents have access. We work through the OWASP LLM risk classes and add whatever your architecture invites. You get the working payloads, not a severity chart, so your team can reproduce every finding.

Depends entirely on your configuration, not the vendor's certifications. Most AI data leakage we find isn't a platform breach; it's an assistant faithfully surfacing content the asking user already had access to on paper but never in practice. That's why we examine retrieval and permissions before testing prompts. The platform is usually fine. The wiring usually isn't.

Yes, and it's a sensible baseline for Canadian organisations. ITSAP.10.049 organises AI security into three pillars covering adversarial use of AI, protecting AI systems, and protecting users and processes. Our threat model maps findings to it, which helps when you're explaining the work to a board or a regulator that already knows the document. It's free to read, and we'd rather you checked our work against it.

There's no Canadian AI statute. AIDA died when Parliament was prorogued in January 2025 and no successor has been tabled. What binds you is privacy law, your sector regulator, and your client contracts. PIPEDA covers any personal information your model can reach, and OSFI has published a frontier AI bulletin for federally regulated financial institutions.

Let's connect

A senior SMEnode engineer replies within an hour, 24/7.