AI Agent Security for Canadian SMBs 2026 | Agentic AI Risk Guide

In June we published an AI policy playbook for Canadian businesses. It was about a specific problem: employees pasting customer lists, contracts, and financial data into chatbots that were never approved and are not covered by any agreement you have signed. That problem has not gone away. But over the past year a second one has arrived, and it is structurally different in a way that matters.

The chatbot problem was about data going out. An employee typed something into a box, and information left your control. The agentic problem is about actions coming back in. An AI agent does not just read and answer. It is given credentials, a browser session, or an API token, and then it clicks buttons, fills forms, sends messages, approves items, moves files, and executes multi-step workflows on a person's behalf, with that person's full permissions, without a human reviewing each step.

The security question therefore changes from "what did we tell it" to "what is it allowed to do, and would we know if it did something else." Most Canadian businesses in the 20 to 200 user range have not asked that second question yet, and a meaningful number already have agents running in their environment that nobody inventoried, approved, or monitored.

This article covers what actually changed, the specific failure modes worth understanding, why AI agents create an identity problem your existing tooling was not built for, and a practical control framework you can implement without a security team or an enterprise budget. 

The Scale of the Gap

The industry data on this is unusually consistent, and unusually uncomfortable.

A Dark Reading readership poll found that 48% of cybersecurity professionals identified agentic AI and autonomous systems as the top attack vector heading into 2026, ranking it above deepfake threats and passwordless adoption. That is a notable result, because deepfakes have dominated the security conversation for two years.

The adoption and governance figures explain why. Research from SailPoint reported that roughly 80% of organizations had already encountered agentic AI risks, while Deloitte found only about 21% of IT leaders reporting a mature agentic AI governance program in place. Separate survey work found that the large majority of technical teams had moved past planning into active testing or production, and that only a small fraction of those agents went live with full security and IT approval.

The gap between those two sets of numbers, widespread deployment against sparse governance, is where the risk sits. It is not a future problem being forecast. It is a present condition being measured.

For a smaller organization there is an additional wrinkle. Enterprises at least have a security function to be overwhelmed. In a 60-person business, the person who would notice an unapproved agent is the same person running the help desk, managing the Microsoft tenant, and onboarding new hires. Agents are being adopted by individual employees to make their own work faster, which means adoption is decentralized, well-intentioned, and largely invisible. 

What Actually Changed: From Reading to Acting

It is worth being precise about the shift, because the word "AI" is doing too much work in most conversations.

Generation

You ask a model for text, code, or a summary. It returns output. The risk is data exposure on the way in and inaccuracy on the way out. This is what our June policy guidance addressed, and acceptable-use rules plus data classification handle most of it.

Retrieval

The model is connected to your documents so it can answer using your own content. Microsoft 365 Copilot is the common example. The risk shifts to permissions: the assistant surfaces whatever the user can technically reach, which is frequently far more than anyone intended. Businesses that never cleaned up oversharing in SharePoint discover it here, which is why our Copilot guidance leads with permission hygiene rather than licensing.

Agency

The model is given tools and a goal, and it takes actions in sequence to achieve the goal. It sends the email. It updates the record. It approves the invoice. It runs the script. It navigates the website and completes the form.

This last category is genuinely different, for three reasons. The system takes actions with real-world consequences that are not individually reviewed. It holds credentials or an authenticated session in order to do so. And its behaviour is determined partly by content it encounters along the way, which means an attacker who controls that content has a path to influencing what it does.

The Browser Agent Problem

The sharpest version of this risk is the AI agent operating inside a browser, because of one detail that is easy to miss: it inherits the user's authenticated sessions.

Consider what is logged in on a typical employee's work browser right now. Microsoft 365 or Google Workspace. The CRM. The accounting system or the banking portal. The payroll platform. An HR system with employee records. A password manager extension. Internal admin tools. A browser agent acting on that profile operates with the full authenticated access of that person across every one of those applications simultaneously.

Security analysis of this category has converged on a consistent list of exposure points: indirect prompt injection, sensitive data disclosure, excessive agency, and a visibility gap in which conventional data loss prevention, cloud access security brokers, and endpoint controls cannot observe what an autonomous agent is doing inside the browser runtime. That last point is the one that should concern anyone who has bought tooling on the assumption it covers this. Those controls were designed to watch network traffic, endpoints, and cloud APIs. An agent operating inside an authenticated browser session is largely outside their field of view.

The tempting response is to block it at the firewall. That rarely holds. Staff who need the productivity will use AI browser features on a personal device, a personal account, or an unmanaged extension, which moves the activity out of sight rather than eliminating it. The more durable approach is to permit approved use with visibility and constraints in place, which is the same conclusion we reached about shadow AI generally.

Six Failure Modes Worth Understanding

1. Indirect prompt injection

The agent reads content as part of its task, and that content contains instructions. A web page, a PDF, a calendar invite, a support ticket, or an incoming email includes text directing the agent to do something the user never asked for: forward a document, change a record, visit a URL, or reveal what it has access to. The agent cannot reliably distinguish instructions from the person who employs it and instructions embedded in the data it was asked to process.

This is the defining vulnerability of the category, and it has no clean technical fix. The mitigation is architectural: constrain what the agent is permitted to do, so that a successful injection has a small blast radius.

2. Excessive agency

An agent given broader permissions than its task requires, because scoping permissions precisely is harder than granting the account it already has. The classic pattern is an integration created with full administrative access because a read-only scope threw an error during setup and nobody went back to fix it.

3. Non-human identity sprawl

Every agent, integration, and automation needs to authenticate, which means an API key, a service account, an OAuth token, or a certificate. These are non-human identities, and they behave differently from employee accounts in ways that matter: they rarely have MFA, they frequently do not expire, they are often shared across multiple uses, they are usually created outside any joiner-mover-leaver process, and nobody is notified when the person who created one leaves the company.

We wrote about non-human identity management briefly in January. The agentic wave has turned it from an advanced topic into a mainstream one, because agent adoption multiplies these credentials faster than any previous technology shift.

4. Credential and session theft

If an attacker steals an agent's API key or session token, they can operate as that trusted agent. Your systems see requests arriving from a legitimate account with valid credentials, behaving roughly as expected, at whatever hours that agent normally runs. Distinguishing the real agent from an attacker holding its credentials is genuinely difficult, and hardcoded keys in configuration files and code repositories remain common.

5. Memory and context accumulation

Agents that retain context across sessions accumulate whatever they have handled: customer data, internal decisions, financial figures, occasionally credentials. Without deliberate limits on retention, the agent's context becomes an unmanaged store of sensitive information that sits outside your data inventory and outside your retention policy.

6. Cascading and chained failures

Agents increasingly invoke other agents and tools. One faulty or manipulated step propagates. In a business context the realistic version is mundane rather than dramatic: an agent misreads a supplier's revised banking details from a compromised email thread, updates the vendor record, and the next payment run executes correctly against incorrect data. No system was breached. The fraud is simply now inside your master data.

Where This Meets Business Email Compromise

The single most expensive incident for a Canadian business in this size range is not ransomware. It is a fraudulent payment or a vendor banking change approved under time pressure. Agentic automation intersects with that risk in a way that deserves attention before it becomes a claim.

The control that reliably stops payment fraud is human and procedural: a call to a known number, to a person you have spoken to before, before any banking detail changes. It works precisely because it introduces a deliberate, out-of-band human check into a moment of pressure.

Automation is very good at removing exactly that kind of friction. An agent that reads invoices from a mailbox, extracts payment details, and updates records has been built specifically to eliminate the step where a person looks carefully. If you are automating any part of an accounts payable or vendor onboarding workflow, the verification step is the one part that must remain human, and it should be documented as a deliberate exception rather than left as an oversight nobody wrote down.

This is worth raising with your insurer as well. Social engineering and funds transfer fraud coverage frequently carries conditions requiring documented verification procedures. If an automated workflow has quietly removed the procedure your policy assumes exists, you may have created a coverage problem alongside a security one.

A Control Framework for 20 to 200 Users

You do not need an enterprise AI governance program. You need seven things, in this order.

1. Inventory what already exists. Before policy, discovery. Review OAuth application consents in your Microsoft 365 or Google Workspace tenant, which is where most agent integrations appear first and where most businesses find something they did not know about. List browser extensions with broad permissions across managed devices. Review Copilot agents or equivalent low-code automations your staff have built. List API keys and service accounts in your core systems and identify an owner for each. Expect this to take a few hours and to produce surprises.
2. Classify by consequence, not by tool. Sort agent use into three tiers. Read-only and drafting, where the agent produces something a human sends or approves. Acting on internal systems, where it modifies records or files. Acting externally or financially, where it sends communications on your behalf, changes vendor or payment data, or touches customer-facing systems. The third tier needs approval, documented scope, and monitoring. The first tier mostly needs guidance.
3. Give every agent its own identity. Never let an agent operate on a human's account or a shared administrative credential. A dedicated service identity per agent gives you scoped permissions, an audit trail attributable to that agent, and the ability to revoke it without disrupting a person's work. This single control does more than any other to make the rest tractable.
4. Scope permissions to the task and set expiry. Least privilege applies to agents more urgently than to people, because an agent will use every permission it has if a task or an injected instruction leads there. Credentials should expire on a defined schedule, and rotation should be a calendar item with an owner rather than an intention.
5. Define what requires a human in the loop. Write down the actions an agent may never take unattended. A defensible starting list for most businesses: sending external email on behalf of an executive, changing vendor banking details, approving or releasing payment, modifying user permissions or security settings, deleting data, and publishing anything publicly. Keep the list short enough that people remember it.
6. Bring agent activity into monitoring. Agent actions should appear in the same telemetry your detection service watches, and the specific signals worth alerting on are OAuth consent grants, new service principal creation, unusual data access volumes, and permission escalations. This is the point where agentic risk stops being a policy question and becomes a detection question, which is why it belongs in the same conversation as your monitoring coverage rather than in a separate AI initiative.
7. Add agents to your offboarding checklist. When an employee leaves, someone disables their account. Almost nobody disables the three automations that employee built, which continue running on credentials nobody owns. Add a line to the checklist: what did this person automate, and who owns it now.

The Canadian Regulatory Angle

Two points of context for Canadian businesses, offered as orientation rather than legal advice.

Privacy obligations apply regardless of what is doing the processing. Under PIPEDA and the provincial private-sector statutes in Alberta, British Columbia, and Quebec, accountability for personal information stays with your organization when a third-party tool or an automated system handles it. An agent that reads customer records and sends them to a vendor's model for processing is a disclosure of personal information, and the accountability principle does not distinguish between a human doing that and an agent doing it.

Québec's Law 25 is the strictest regime in the country and reaches any organization holding personal information about Québec residents regardless of where the organization sits. Automated decision-making and cross-border transfers both carry specific obligations under it, which makes agent workflows touching Québec personal data a documented assessment rather than an assumption.

Data residency and jurisdiction are separate questions. Where the agent's provider processes and retains your data, and under which country's legal jurisdiction that provider sits, are both worth establishing before an agent handles regulated records. Storage in Canada and Canadian legal jurisdiction are not the same thing, and the distinction is increasingly consequential.

On AI-specific law: federal AI legislation in Canada has not landed in the form once proposed, and businesses should plan against existing privacy, consumer protection, and sector-specific obligations rather than waiting for a dedicated AI statute to tell them what to do. The practical compliance question for a 60-person company in 2026 is not "are we AI Act compliant" but "can we demonstrate what our automated systems have access to, what they did, and who approved it."

What This Looks Like in Practice

A professional services firm with 75 staff engaged us after their operations manager built a genuinely useful automation: an agent that monitored a shared mailbox, extracted details from incoming client documents, and updated their practice management system. It saved several hours a week. It had been running for four months.

Three findings from the review. The agent authenticated using the operations manager's own account, so every action it took was attributed to her in the audit log and its permissions were her permissions, which included administrative access she had been granted for an unrelated reason two years earlier. Its scope included the ability to modify client billing records, which the task did not require. And because it processed inbound email content, any instruction embedded in a document sent to that mailbox by an outside party entered its context.

None of this was negligence. It was a competent person solving a real problem with a tool that made it easy to do so and offered no guidance on scoping. The remediation took under a day: a dedicated service identity, permissions narrowed to the three operations the task actually needed, the billing modification capability removed, and the agent's activity added to monitoring. The automation still runs and still saves the same hours.

That is the outcome worth aiming for. The goal is not to stop this. Businesses that block agentic tooling outright will lose ground to businesses that adopt it with controls, and staff will route around the block regardless. The goal is that when an agent does something unexpected, you find out in minutes and the damage is bounded by permissions you chose deliberately. 

GAM Tech Differentiators: AI Governance for Canadian SMBs

GAM Tech has supported Canadian businesses with 20 to 200 users since 2012, from eight offices across Alberta, British Columbia, Ontario, and Quebec, with bilingual support in Ottawa and Montréal.

On agentic AI specifically:

• We run agent discovery as an assessment, not a questionnaire. OAuth consent review, service principal enumeration, browser extension audit, and low-code automation inventory in your actual tenant. Most engagements surface at least one agent nobody had inventoried.
• No AI-only triage in our own service desk. We hold ourselves to the standard we recommend. Automation enriches and correlates; a GAM Tech employee decides what happens next. When the alert is ambiguous and the action is disruptive, that judgment is not something we delegate to a model.
• Identity-first architecture. Dedicated service identities, scoped permissions, and credential expiry are how we implement automation for clients, which means the audit trail exists before anyone asks for it.
• SOC2 certified, B Corp certified, Canadian-owned and built without outside capital. The controls we recommend are controls we are independently audited against, and we are not a subsidiary answering to a foreign parent.
• 24/7 internal staff, never outsourced, with a 5-minute response commitment. Agent activity monitoring is only as good as the person who responds to it.

Project packs are included in our managed services agreements. Agent inventory, permission remediation, and policy documentation are not a separate scoping exercise every time. 

Frequently Asked Questions

What is agentic AI? Agentic AI refers to systems given a goal and a set of tools, which then take a sequence of actions to achieve that goal with limited human review of each step. The distinction from a chatbot is action: an agent does not only produce text, it clicks, sends, updates, and executes on your systems.

Why are AI agents a bigger security risk than chatbots? A chatbot risks data leaving your control. An agent holds credentials or an authenticated session and takes actions inside your systems, which means a compromise or a manipulated instruction produces consequences rather than just disclosure. Agents also create non-human identities that most access management processes were never designed to handle.

What is prompt injection, in business terms? It is when content the agent processes contains instructions it follows. A supplier's PDF, an inbound support ticket, a web page, or a calendar invite can carry text directing the agent to take an action nobody authorized. There is no reliable technical fix, so the mitigation is limiting what the agent is permitted to do.

Should we just block AI browser agents? Blocking rarely holds, because staff will use AI features on personal devices or unmanaged accounts to get their work done, which moves the risk out of your visibility rather than removing it. Permitting approved use with scoped permissions and monitoring is more durable than a prohibition people route around.

What is a non-human identity? Any credential used by software rather than a person: API keys, service accounts, OAuth tokens, certificates. They matter because they usually lack MFA, frequently never expire, are often created outside any formal process, and are rarely reviewed when the person who created them leaves.

How do we find out what agents are already running in our environment? Start with OAuth application consents in your Microsoft 365 or Google Workspace tenant, then enumerate service principals, audit browser extensions with broad permissions on managed devices, and review any low-code automations or Copilot agents staff have built. This is where unapproved agents almost always surface first.

Does Microsoft 365 Cop count as an agent? Standard Copilot is primarily retrieval and generation, and its main risk is permissions, since it surfaces whatever a user can technically reach. Copilot agents and Copilot Studio builds are genuinely agentic, take actions, and should be governed accordingly.

Do Canadian privacy laws apply to what an AI agent does with customer data? Yes. Accountability for personal information stays with your organization under PIPEDA and the provincial statutes regardless of whether a person or an automated system handles it. An agent disclosing personal information to a third-party processor is a disclosure your organization is answerable for.

What should never be automated? A defensible baseline for most businesses: sending external email as an executive, changing vendor banking details, approving or releasing payment, modifying permissions or security settings, deleting data, and publishing publicly. The payment verification step in particular should remain human, because that friction is the control.

Where do we start if we have done nothing? Inventory before policy. Spend an afternoon finding out what is already connected to your tenant and who owns it. A written policy that governs agents you have not yet identified is a document rather than a control.

Find Out What Is Already Connected

There is a good chance something in your environment is currently authenticated, taking actions, and not on anyone's list. That is not a failure of discipline. It is the predictable result of tooling that made automation easy and said nothing about scoping it.

GAM Tech offers an AI agent and identity assessment across all eight of our Canadian markets. We enumerate what is connected to your tenant, what permissions each item holds, which are unowned, and where an agent can take an action nobody approved. You get a written inventory, a scoped remediation plan, and policy language you can actually use, whether or not you engage us to implement it.

Call 1-833-GAM-TECH or book a consultation. Since 2012, SOC2 certified, B Corp certified, 24/7 internal staff, never outsourced.