Security Insights

Artificial intelligence (AI) agents are moving quickly from experiments to real business environments. They are no longer just answering questions. They are beginning to access systems, retrieve information, use tools, and take actions on behalf of users. That shift creates a security challenge that most organizations have not fully reckoned with yet.

A recent vulnerability involving NVIDIA’s NemoClaw and the OpenClaw AI agent framework is a useful example of what that challenge actually looks like in practice. The issue was not simply a vulnerable AI model. It was the infrastructure surrounding the model. That distinction matters for anyone responsible for keeping a business secure.

The Story in Plain English

Researchers from Cyera’s Oasis Identity Research discovered a networking configuration flaw involving NemoClaw, NVIDIA’s tool for deploying the OpenClaw AI agent framework inside OpenShell sandboxes. At the center of the issue was Ollama, an open source runtime commonly used to run AI models locally.

NemoClaw configured Ollama in a way that made its application programming interface (API) reachable beyond the local machine. That API also did not require authentication. Together, those two facts created an opening for an attacker.

The researchers demonstrated that a malicious webpage could use a technique called DNS rebinding to reach the local Ollama server from outside. Once that access was established, an attacker could interact directly with the model server: enumerating available models, running inference, modifying or deleting models, and manipulating the model’s chat template.

That last part is the one worth sitting with. The chat template helps determine how an AI agent’s instructions are processed. Manipulating it could let an attacker plant hidden instructions that persist across future interactions, not just a single bad prompt in a single session. The underlying environment the agent depends on could be altered and left that way.

Why “Prompt Injection” Doesn’t Tell the Whole Story

Prompt injection has become one of the most talked about risks in AI security. The idea is simple enough: an attacker places instructions somewhere an AI system can see them, and the system follows those instructions instead of behaving as intended.

The NemoClaw case points to something broader than that. The security problem is not always inside the prompt. It can live in the infrastructure around the AI entirely.

Think about how a traditional application gets secured. Nobody protects an application by locking down only the user interface. A serious security review also looks at authentication, APIs, network connections, databases, permissions, operating systems, logging, and monitoring, along with the risk carried by third-party dependencies. AI systems need that same mindset. The model is only one piece of a much larger system.

The Security Boundary Around AI Keeps Expanding

As AI becomes more capable, the number of components it touches grows with it. An AI agent might move through a chain that runs from the user to the agent itself, to the underlying model, to APIs, into business applications, into company data, and out to external tools. Every link in that chain is a potential security boundary. If one component is compromised, the effects can travel to the next one.

This is why AI security cannot simply mean “we put the agent in a sandbox.” A sandbox reduces risk. It does not automatically make everything inside or around it trustworthy.

Applying the Zero Trust Lesson to AI

This is where a familiar cybersecurity principle becomes newly relevant. One of the core ideas behind Zero Trust is straightforward: never assume something is trustworthy simply because of where it sits. That principle applies surprisingly well to AI infrastructure.

Being local, internal, sandboxed, or behind the firewall is not, on its own, a reason to trust a component. The better approach is to authenticate it, authorize it, restrict it, monitor it, and log it. The right question is not “is this inside our environment?” It is “what is this component allowed to communicate with, and what is it allowed to do?”

Why This Matters to the Business, Not Just IT

For a company experimenting with AI agents, this can initially sound like a highly technical concern. The business implications are actually quite direct.

Picture an AI agent with access to internal documents, customer records, email, customer relationship management (CRM) systems, financial information, source code, and cloud infrastructure. That access exists because the agent needs it to do useful work. But if an attacker can manipulate the agent, or the infrastructure it depends on, those same permissions become part of the attack path.

The more capable an AI agent becomes, the more its surrounding security architecture matters. Every organization deploying one should be able to answer a simple question before it goes into production: if an attacker gains control of this agent, what can they reach?

Sandboxing Still Has a Place

None of this means sandboxing is a bad idea. Isolation remains a genuinely useful control. The mistake is treating one control as an entire security strategy.

A sandbox can limit what an application touches, but organizations still need to think through network exposure, authentication, authorization, API security, secrets management, identity, data access, model integrity, logging, monitoring, and software supply chain risk. Security has always worked best as a layered system of controls, and AI should not be treated as an exception.

A Newer Layer to Think About: Agent-to-Model Communication

Most of the public conversation about AI security focuses on the interaction between a user and an AI system. The NemoClaw case is a reminder that agent-to-model, agent-to-API, agent-to-tool, and agent-to-data interactions deserve their own scrutiny.

• Who can make the request
• What they can request
• Which model is being used
• What data is being passed along
• What tools the agent can call, and what permissions it holds
• Whether the request can be monitored and suspicious behavior detected
• Whether the action can be stopped before it completes

These used to be theoretical questions. They are quickly becoming part of the standard security architecture for any AI-powered business.

What Business Leaders Can Do

Nobody needs to become an AI security specialist to start asking the right questions. Organizations deploying or piloting AI agents can start with a few practical steps:

• Build an inventory of every system, application, API, and data source the agent can reach — it is impossible to assess risk for access nobody has mapped.
• Apply least privilege, so the agent does not automatically inherit the same access as the employee who built it.
• Secure the APIs the agent communicates through with proper authentication, authorization, and monitoring.
• Review the infrastructure that hosts and serves the model, not just the model’s behavior.
• Put monitoring in place so unusual agent activity gets flagged rather than missed.
• Plan for compromise from the start, by asking what happens if this specific agent is taken over, then building controls around that answer.

The Bigger Shift Underway

Early conversations about AI security focused almost entirely on whether someone could trick the model. That question still matters, but the conversation has widened. Now the questions include what the model can access, what the agent is capable of doing, what happens if the agent is compromised, whether an attacker can manipulate the infrastructure around it, and whether abnormal behavior can be caught and stopped before it causes damage.

Those questions move AI security out of prompt engineering and into familiar cybersecurity territory: identity, access control, network security, application security, data security, monitoring, incident response, and supply chain security. The difference is that AI agents can chain many of these components together and act far faster than a person ever could.

The Bottom Line

The NemoClaw vulnerability is a useful reminder that AI security does not stop at the model, and it does not stop at the agent either. It extends across the entire environment that allows the AI system to operate. As organizations hand AI agents more access and more autonomy, the security architecture built around those agents becomes just as important as the model itself.

The goal is not to slow down AI adoption. It is to make sure that when AI is given access to something valuable, there are real controls wrapped around that access.

That is the question worth answering before AI agents become deeply embedded in day-to-day business operations. The organizations that get the most value out of AI will not be the ones that hand their agents the most access. They will be the ones that understand exactly what their agents can do, where they can go, and what happens when something goes wrong.

Related: Zero Trust Is Not a Product — It’s a Strategy — on the principle behind this post’s approach to AI infrastructure — and Identity Is No Longer an IT Problem. It Is a Business Strategy. for a closer look at the access and permissions layer this post touches on.

Ransomware remains one of the most disruptive cybersecurity threats facing organizations today. But the nature of ransomware attacks has changed significantly.

The traditional image of ransomware is straightforward: an attacker gains access to a network, encrypts files, and demands payment in exchange for restoring access.

Modern attacks can be considerably more complex.

Attackers may spend days or weeks inside an organization before causing visible disruption. During that time, they can identify valuable systems, compromise additional accounts, locate sensitive information, discover backup infrastructure, and determine which systems would create the greatest operational impact.

By the time a ransom demand appears, much of the attack may already be complete.

For organizations, this creates a broader cybersecurity challenge. The question is no longer simply whether ransomware can be prevented. It is whether an organization can limit the damage when an attacker gets inside.

Ransomware Is No Longer Just an Encryption Problem

Ransomware was once primarily associated with encrypted files and a ransom payment. That remains part of the threat, but modern ransomware campaigns can involve multiple stages and multiple forms of pressure.

Attackers may:

• Compromise employee or administrator accounts
• Move laterally across an organization’s environment
• Identify critical business systems
• Steal sensitive information
• Target backup infrastructure
• Disrupt business operations
• Threaten to publish stolen information
• Use operational disruption as leverage

This means that even an organization with reliable backups may still face serious consequences. Data exposure, operational downtime, regulatory obligations, legal costs, customer impact, and reputational damage can continue even when encrypted systems can eventually be restored.

The objective is increasingly broader than simply locking files.

The Attack Can Begin Long Before the Ransom Note

One of the most important characteristics of modern ransomware attacks is that the visible disruption may occur long after the initial compromise.

Consider a scenario in which an employee’s credentials are stolen.

At first, nothing appears unusual. There is no ransom note. No widespread outage. No obvious malware infection. The attacker simply has access to a legitimate account.

From there, the attacker may begin determining:

• What systems can this account access?
• Which accounts have elevated privileges?
• Where is sensitive information stored?
• Which systems are critical to operations?
• Where are the backups?
• Can those backups be modified or deleted?
• Which systems would cause the greatest disruption?

This type of activity makes ransomware detection more challenging. An attacker using legitimate credentials and existing administrative tools may not immediately look like a traditional malware threat. That is why organizations need visibility into behavior and access, not just malicious files.

The Real Security Question: What Happens After the Initial Compromise?

No organization can guarantee that an attacker will never gain access. Credentials can be stolen. Software vulnerabilities can be exploited. Employees can be targeted through phishing. Third-party suppliers can be compromised. Security controls can fail.

The more useful question is what happens next.

If one employee account is compromised, can the attacker access critical systems? If a workstation is compromised, can the attacker move to servers? If administrative credentials are obtained, what can the attacker change? If backup infrastructure is accessible, can the attacker disable recovery? If sensitive data is stolen, how quickly will the organization know?

These questions shift cybersecurity away from a simple perimeter-defense model and toward containment and resilience. The goal is not only to prevent an intrusion. It is to prevent a single intrusion from becoming a company-wide crisis.

Five Ways Organizations Can Reduce Ransomware Impact

1. Apply Least Privilege

Employees, applications, service accounts, and vendors should receive only the access required to perform their responsibilities.

Excessive permissions can dramatically increase the potential impact of a compromised account. If an employee account only has access to the systems necessary for that employee’s role, an attacker operating through that account has fewer opportunities to move through the environment.

Least privilege is not a new cybersecurity concept, but ransomware continues to demonstrate why it matters.

2. Protect and Test Backups

Backups remain one of the most important defenses against ransomware. However, simply having backups does not guarantee recovery.

Organizations should determine:

• Whether attackers can access backup systems
• Whether backups can be deleted or modified
• Whether isolated or offline copies exist
• How quickly critical systems can be restored
• Whether restoration procedures have actually been tested

A backup strategy should be treated as part of business continuity, not simply as an IT task. A backup that has never been successfully restored provides far less confidence than an organization may assume.

3. Strengthen Identity Security

Identity has become one of the most important components of ransomware defense.

Organizations should protect privileged accounts, enforce strong authentication, monitor unusual account activity, and regularly review access permissions.

Multi-factor authentication can significantly reduce the risk associated with stolen credentials, but organizations should also consider stronger authentication methods where appropriate, particularly for privileged and highly sensitive accounts.

The goal is to make it significantly harder for an attacker to turn one compromised identity into broader access.

4. Monitor for Abnormal Behavior

Traditional security controls often focus on detecting known malicious activity. Ransomware defense also requires organizations to recognize activity that is unusual for a particular user, device, or environment.

Examples may include:

• A user suddenly accessing systems they have never used before
• Large amounts of data being downloaded
• Unusual administrative activity
• Unexpected changes to backup infrastructure
• Login activity inconsistent with normal behavior
• A workstation communicating with unusual internal systems

None of these activities automatically indicate ransomware. But unusual behavior can provide valuable signals when multiple events are considered together. The ability to identify suspicious activity before widespread disruption occurs can significantly improve an organization’s response.

5. Test Incident Response and Recovery

An incident response plan sitting in a document does not guarantee that an organization is prepared. Organizations should regularly test how they would respond if critical systems became unavailable.

Questions should include:

• Which systems would be restored first?
• Who has authority to make that decision?
• How would employees communicate if normal systems were unavailable?
• How would customers be informed?
• When would legal, privacy, regulatory, or law enforcement teams become involved?
• How long could the organization continue operating without its critical systems?

These are not purely cybersecurity questions. They are business continuity questions.

Ransomware Resilience Requires More Than Security Tools

Organizations often measure cybersecurity maturity by looking at the technologies they have deployed: endpoint detection and response, firewalls, multi-factor authentication, security information and event management, vulnerability management, email security, security awareness training.

All of these controls can play an important role. But having more security products does not automatically mean an organization is resilient to ransomware.

The more important question is whether those controls work together to provide layers of defense. If one control fails, can another detect the activity? If an account is compromised, can access be contained? If an attacker reaches a critical system, can the activity be detected? If systems are encrypted or taken offline, can they be restored? If sensitive information is stolen, can the organization respond effectively?

This is the principle of defense in depth: rather than relying on a single security control, organizations build multiple layers that reduce the likelihood that one failure becomes a catastrophic event.

The Goal Is Not Perfect Security

Perfect security does not exist. Organizations will continue to face phishing attacks, stolen credentials, software vulnerabilities, supply chain risks, insider threats, and new attack techniques.

The objective is therefore not to assume that every attack can be prevented. The objective is to build an environment in which an attacker has fewer opportunities to move, fewer systems to compromise, fewer privileges to abuse, and fewer ways to disrupt critical operations.

This is where cyber resilience becomes just as important as prevention. A resilient organization assumes that something will eventually go wrong. It prepares for that possibility before the crisis occurs.

Questions Business Leaders Should Ask

Business leaders do not need to become cybersecurity specialists to improve their organization’s ransomware readiness. They should, however, be able to ask their IT and security teams the right questions.

1. If one employee account is compromised, how far could an attacker get?

This helps reveal excessive permissions and potential lateral movement paths.

2. Can an attacker access or delete the organization’s backups?

If the answer is yes, the organization’s recovery strategy may need to be reconsidered.

3. When was the last successful restoration test?

A documented backup is not the same as a proven recovery capability.

4. How quickly would the organization detect unusual activity?

Early detection can provide valuable time to contain an attack before it becomes widespread.

5. What are the organization’s most critical systems?

Understanding which systems are essential to operations helps prioritize recovery during an incident.

6. How long could the business operate without those systems?

This question connects cybersecurity directly to business continuity and operational resilience.

The Bottom Line

Ransomware is no longer simply a malware problem. It is an identity, access, detection, resilience, and business continuity problem.

Organizations should continue investing in prevention, but prevention cannot be the only objective. A stronger security strategy asks a second question:

Limiting access, protecting backups, strengthening identity security, monitoring abnormal behavior, and regularly testing recovery can significantly reduce the potential impact of a ransomware incident.

The strongest organizations are not necessarily those that assume they will never be breached. They are the organizations that prepare for what happens when something eventually gets through.

Cybersecurity is ultimately about protecting the ability of the business to keep operating.

Related: Your Business Isn’t Too Small to Be Hacked. It’s Too Small to Recover. — on why SMBs are more exposed than they realize — and Identity Is No Longer an IT Problem. It Is a Business Strategy. for a closer look at the identity layer this post touches on.

A company can invest heavily in cybersecurity controls and still experience a breach because of one simple assumption: “Our vendors are secure.”

Modern businesses no longer operate inside a single security boundary. Organizations rely on cloud platforms, software providers, IT support partners, and external vendors every day. Every connection creates convenience. Every connection also creates risk.

Recent incidents, including breaches involving third-party support platforms, highlight an important lesson for organizations of all sizes: an organization’s security is only as strong as the partners who have access to its data.

The Growing Third-Party Risk Problem

Many businesses carefully protect their own networks but pay less attention to the companies connected to them. A vendor may have access to customer information, financial documents, internal communications, business systems, and sensitive operational data.

From an attacker’s perspective, compromising a trusted vendor can sometimes be easier than directly attacking a well-defended organization. This is why third-party risk has become a major focus for security teams. The question is no longer only “how secure are we?” — it is also “how secure are the organizations connected to us?”

Why This Matters for Canadian SMBs

Large enterprises often have dedicated teams managing vendor security reviews. Many small and medium-sized businesses do not have the same resources. A typical SMB may rely on Microsoft 365 for business operations, accounting software for financial data, a managed service provider for IT support, and several SaaS applications for daily workflows.

These tools improve productivity, but they also expand the organization’s attack surface. A compromised vendor account or poorly secured integration can create a path into the business. The risk is not just technical — it can lead to business disruption, customer trust issues, regulatory concerns, financial impact, and lasting reputation damage.

Four Questions Every Organization Should Ask Vendors

1. What data do they have access to?

Not every vendor needs access to everything. Organizations should regularly review what information is being shared, who can access it, and whether that access is still required. The principle is straightforward: give vendors the minimum access needed to do their job. This concept — least privilege — is one of the foundations of a Zero Trust architecture.

2. How do they protect that data?

Security teams should understand a vendor’s security practices rather than assume them. Important questions include: do they use multi-factor authentication? Do they monitor for suspicious activity? Do they have an incident response plan? Do they regularly assess their own security controls?

Trust is important. Verification is better.

3. What happens if the vendor is compromised?

A security relationship should not end when a contract is signed. Organizations should understand how quickly they will be notified of a breach, what information will be provided, and who is responsible for response activities. A breach response plan is only effective if everyone knows their role in advance.

4. Are we reviewing vendor access regularly?

Vendor relationships change over time. Employees leave. Permissions remain. Business needs evolve. Access reviews should be an ongoing process, not a one-time activity at onboarding. Without a structured review cycle, old access accumulates quietly and becomes invisible risk.

The Bigger Picture

Cybersecurity is no longer only about protecting an organization’s own environment. It is about managing an ecosystem of relationships. The strongest security programs combine strong identity controls, least privilege access, vendor risk management, continuous monitoring, and clear incident response plans.

Because in today’s connected world, a trusted connection can become an unexpected entry point. Security is not just about who an organization trusts. It is about how that trust is verified and maintained over time.

Related: You Secured Your Business. Did You Secure Everyone Connected to It? — a deeper look at how supply chain attacks play out in practice — and Your Employees Aren’t Stealing Your Data. They’re Accidentally Sharing It with AI for another angle on how trusted connections create unintended exposure.

Picture this scenario.

An employee is racing to finish a proposal before the end of the day. They copy a few paragraphs into an AI assistant to improve the wording. A few seconds later, they have a polished version ready to send to the client.

Problem solved. Or so it seems.

Hidden inside that prompt might be the client’s name, contract details, pricing, internal notes, or financial information. Without realizing it, the employee may have shared sensitive business information with a third-party AI platform.

There was no hacker. No malicious insider. No security breach. Just someone trying to work a little faster.

This is one of the most overlooked cybersecurity risks facing Canadian businesses today.

AI Is Not the Problem

Let’s be clear. AI tools like ChatGPT, Microsoft Copilot, and Google Gemini have changed how people work. They help employees write faster, summarize documents, brainstorm ideas, and automate repetitive tasks. These tools have legitimate business value.

The problem is not the technology. The problem is that many organizations have not stopped to ask an important question: what happens to our information after it is pasted into an AI tool?

The answer depends on the platform, the account type, and how it is configured. Some services retain prompts for a period of time. Others offer enterprise controls that handle data differently. Many employees do not know the difference, and most organizations have not provided guidance. That is where the real risk begins.

This Is a Visibility Problem

Many organizations hear Zero Trust and immediately think about passwords, multi-factor authentication, or controlling who can access company systems. Those are all important.

But Zero Trust architecture also asks another question: how does sensitive information leave the organization?

Today, one of the easiest ways for data to leave is through AI tools. Employees copy and paste documents. Upload spreadsheets. Ask AI to summarize meeting notes. Review contracts. Rewrite emails. Each action seems harmless on its own. Together, they create a growing blind spot that many organizations are not monitoring. Without visibility into these data flows, the risk accumulates quietly.

Why Data Loss Prevention Matters

This is where Data Loss Prevention (DLP) comes in. Think of DLP as a safety net for an organization’s information.

Instead of only controlling who can access data, DLP helps organizations understand what sensitive information is leaving the business, where it is going, and whether it should be leaving at all. Modern DLP solutions can detect information like customer records, financial data, employee information, or other confidential content before it leaves the environment. Depending on how they are configured, they can alert users, notify administrators, or prevent the information from being shared entirely.

Large enterprises have relied on DLP for years. What is changing is that these capabilities are becoming more practical and accessible for smaller organizations, especially as AI becomes part of everyday work.

The Pattern Emerging in Canadian Organizations

When speaking with smaller organizations across Canada, a clear pattern emerges. There is rarely a deliberate AI strategy in place.

Instead, what exists is something much more common. Different employees adopt different AI tools on their own. Some use personal accounts. Others install browser extensions. Teams experiment with whatever helps them work faster. No one is trying to bypass security. No one intends to create a compliance issue.

But over time, organizations lose visibility into where company information is going and which tools are processing it. The result is not one dramatic security incident. It is a slow accumulation of risk, one prompt at a time.

Why Canadian Businesses Should Pay Attention

For Canadian organizations, this is not just about cybersecurity. It is also about privacy and regulatory compliance.

Under PIPEDA (the Personal Information Protection and Electronic Documents Act), organizations remain responsible for protecting the personal information in their custody, even when employees are using third-party services as part of their work. Organizations operating in Quebec must also consider Law 25, which introduced stronger privacy obligations including requirements to assess certain technologies that process personal information.

Whether an organization has five employees or five hundred, understanding how AI tools are being used has become part of good governance. The regulatory landscape is tightening, and visibility is the first step toward compliance.

Three Steps to Start This Week

Organizations do not need a large security budget to make meaningful progress. Start with three straightforward actions.

• Inventory what’s actually being used. Ask employees which AI tools they are actually using — not just the ones the organization has approved. This inventory reveals the true picture and helps identify gaps in policy. Most organizations are surprised by what they find.
• Create a simple AI usage policy. Clearly identify the types of information that should never be entered into public AI tools: customer data, employee information, financial records, confidential contracts, or source code. It does not need to be a lengthy document — a clear, one-page guideline is enough to start changing behaviour.
• Consider technical safeguards. New solutions are emerging that help businesses understand how AI tools are being used and reduce the risk of sensitive information being shared unintentionally. Visibility comes before control. Start with what you know.

Final Thoughts

The biggest AI security risk for many organizations is not hackers. It is well-intentioned employees using powerful tools without clear guidance or safeguards.

AI is here to stay, and that is a good thing. The challenge is not deciding whether to use AI. It is making sure an organization’s information stays protected while doing so.

Related: What Shadow AI Is Doing to Canadian Businesses Right Now — on the broader pattern of unsanctioned AI adoption across Canadian businesses — and Canada’s Privacy and AI Reckoning for the regulatory context behind these risks.

There is a pattern that shows up in nearly every cybersecurity risk assessment done with small and medium-sized businesses. The business has done the right things. A firewall is in place. Staff have gone through security awareness training. Software is kept up to date. The owner feels reasonably confident about where things stand.

And then the real problem surfaces. Not inside the business. Around it.

A vendor with access that was never reviewed. An IT provider holding the keys to everything. A contractor from a project last year whose login is still active.

That is what a supply chain attack looks like in practice. And it is one of the most common and underappreciated ways businesses are getting compromised right now.

What a Supply Chain Attack Actually Is

The term sounds technical and distant. The concept is not.

Instead of trying to break through a business’s defenses directly, an attacker finds someone who already has a trusted connection to that business and goes through them instead. A software tool the business relies on. The IT support company they have worked with for years. A third-party service that connects to their systems to deliver some function.

From the business’s perspective, that access looks completely normal. Because it is coming from someone they already trust. That is exactly what makes it so difficult to detect.

Vendors, contractors, and third-party service providers are those spare keys.

The Blind Spot That Keeps Appearing

Risk assessments consistently turn up the same findings, and they consistently catch business owners off guard.

Software tools set up years ago with broad access to everything, never revisited since the initial setup. IT providers with deep access to client systems but no clear documentation of what that access actually covers. Contractors from completed projects whose accounts are still sitting open and active.

Nobody made a deliberate bad decision. Access gets added over time as the business grows and changes, and it rarely gets removed or reviewed. Each one of those connections becomes a door that an attacker could walk through.

The detail that lands hardest is that the business owner had no idea. They believed they were in good shape because their own systems looked fine. The exposure was sitting in the relationships around the business the entire time.

Why Attackers Choose This Route

Attackers approach their work practically. If a business has strong internal defenses, they are not going to keep trying to force their way through directly. They are going to look around and identify which vendor or partner connected to that business represents an easier entry point.

Once inside through that trusted connection, an attacker can move through the environment without triggering obvious alerts. Because from a security standpoint, the access looks legitimate. It is coming from a source the business already recognizes and trusts.

This is the same dynamic behind some of the largest and most damaging breaches in recent years. The organizations that got hurt had done everything right internally. The attackers simply found a weaker door through someone those organizations trusted.

For small businesses, the exposure is compounded by the fact that most have no formal process for assessing the security practices of the third parties they connect with. The question of how secure a vendor is rarely comes up until after something has gone wrong.

What Can Be Done Without a Security Team or Big Budget

Managing third-party risk does not require a dedicated security program or specialist staff. It requires being more deliberate about something most businesses have never formally looked at.

• Build a third-party inventory. Make a list of every vendor, IT provider, contractor, and software tool that has access to your systems — even informally. Most organizations have never done this. Having that picture in one place is meaningful progress on its own.
• Review access honestly. For each entry on that list, ask one question: does this connection still need the access it has? The answer is often no. Removing access that is no longer necessary reduces your attack surface immediately and costs nothing.
• Establish a before-you-connect habit. For any new vendor or contractor going forward, get clear on two things: what exactly does this party need access to in order to do their job, and what is the plan for removing that access when the relationship ends?
• Treat offboarding as seriously as onboarding. Removing access at the end of a contract or relationship is just as important as granting it at the beginning. Without a process for this, old connections accumulate quietly and become invisible risk.

Asking the Right Questions of IT and Security Providers

For businesses that work with an external IT or cybersecurity provider, it is entirely reasonable to ask those providers about their own security practices. How do they protect their internal environment? What controls do they have in place to prevent their own systems from being used as a pathway into client environments?

A good provider will answer those questions clearly and confidently. They will have thought about these things and will be able to speak to them without hesitation. If a provider struggles to answer basic questions about how they protect their own environment, that is a signal worth taking seriously.

The providers a business trusts most deeply often have the broadest access. That relationship deserves the same scrutiny as any other significant business decision.

The Exposure That Lives Outside the Walls

A business can do everything right internally and still be compromised because of someone connected to it. That is the central and uncomfortable reality of supply chain risk.

It does not get enough attention in the small business world because the term sounds like a problem for large enterprises with complex global operations. But the dynamic plays out at every scale. The trusted IT provider. The software subscription that has had admin access since the first year of operation. The contractor who wrapped up six months ago.

The fix is not complicated. It starts with visibility, continues with honest review, and becomes a habit around how access gets granted and removed going forward. Paying attention to the connections around the business, not just the controls inside it, is what closes this gap.

Related: Your Business Isn’t Too Small to Be Hacked. It’s Too Small to Recover. — on why SMBs are more exposed than they realize — and Your Firewall Is Fine. Your Employees Are the Problem. for the people-side of the same risk picture.

A lot of Canadian businesses exhaled when Bill C-27 died.

That exhale was a mistake.

For more than two years, Bill C-27 hung over Canadian privacy and technology law as the most significant reform effort in a generation. When it died on the Order Paper in early 2025, many businesses treated the news as a reprieve. The pressure to modernize, the thinking went, had been postponed indefinitely. Compliance could wait.

It could not. And the events of the past few weeks have made that clearer than ever.

How Bill C-27 Died

Bill C-27 died on January 6, 2025, when Parliament was prorogued following the resignation of Prime Minister Justin Trudeau. The bill had aimed to replace parts of Canada’s federal private sector privacy law, the Personal Information Protection and Electronic Documents Act (PIPEDA), and introduce the country’s first legislative framework for regulating high-impact artificial intelligence systems.

The bill bundled three distinct pieces of legislation together. The Consumer Privacy Protection Act would have replaced PIPEDA with stronger consent requirements, clearer rules around automated decision making, and significantly higher penalties for non-compliance. The Artificial Intelligence and Data Act represented Canada’s first attempt at comprehensive AI regulation, targeting systems used in commercial activity. A third act would have created an independent tribunal to hear appeals and enforce penalties, giving the Privacy Commissioner real enforcement teeth for the first time.

When Parliament prorogued, all three pieces of legislation died simultaneously. A snap federal election in the spring of 2025 pushed reform even further down the priority list, and there was no realistic path to reintroducing the bill in its original form.

The result was that Canada continued operating under PIPEDA, a law written in 2000 and largely unchanged since. For many businesses, that felt like the regulatory pressure had lifted. From experience working with Canadian organizations on privacy and security programs, that sense of relief was almost always misplaced. The obligations under PIPEDA never went away. What changed was that the law everyone expected to replace it simply was not there yet.

What the Government Just Launched

On June 4, 2026, Prime Minister Mark Carney launched AI for All, Canada’s new national AI strategy, at an event in Toronto alongside the Minister of Artificial Intelligence and Digital Innovation. The strategy is built around three priorities — trust, opportunity, and sovereignty — and commits the federal government to a five-year program of new legislation, investment, and public programs.

The trust component is the one that matters most for businesses thinking about privacy and compliance risk. The strategy explicitly commits to introducing new legislation, regulations, and standards to protect Canadians’ data, privacy, and children online. It specifically calls out concerns around surveillance pricing, deepfakes, and the inappropriate use of personal information, and commits to a child safety standard that the government intends to raise at this year’s G7 summit.

This is not a discussion paper or a consultation exercise. It is a stated government commitment to legislate, backed by a five-year, multi-billion dollar investment program targeting roughly $200 billion in additional economic growth and 250,000 new AI-related jobs.

For businesses that had quietly shelved their privacy modernization plans after Bill C-27 died, the timeline just moved back into view.

What the Incoming Legislation Is Expected to Include

The direction of upcoming legislation has already been signaled clearly by legal analysts tracking the file throughout 2025 and into 2026. A new federal private sector privacy statute, along with a companion bill establishing an enforcement tribunal, has been expected since the federal budget announcement late last year. That proposed statute is expected to include penalties of up to the greater of $25 million Canadian or five percent of global gross revenue — a dramatic increase over what PIPEDA currently allows.

Children’s privacy and AI-generated deepfakes have been identified publicly as priority areas for the new legislation. Data sovereignty — meaning where Canadian data is stored, processed, and controlled — is also expected to feature prominently.

For context, PIPEDA’s current enforcement mechanism leans heavily on the Privacy Commissioner issuing recommendations and public findings rather than binding penalties. The regime expected to follow AI for All is designed to function much more like the GDPR in Europe, with binding orders and financial penalties substantial enough to change executive behavior.

What Already Applies Right Now

While Parliament works through new legislation, two frameworks are already in force and already being actively enforced.

PIPEDA applies to virtually every private sector organization in Canada that collects, uses, or discloses personal information in the course of commercial activity. The Office of the Privacy Commissioner of Canada can launch investigations, issue public findings detailing non-compliance, and in serious cases refer matters to the Federal Court, which can order organizations to change their practices and award damages to affected individuals.

What has shifted recently is the Commissioner’s posture. Rather than relying primarily on recommendations and voluntary compliance, the Office of the Privacy Commissioner has become increasingly willing to pursue judicial remedies. A joint investigation into OpenAI, conducted alongside provincial privacy regulators in British Columbia, Alberta, and Quebec, concluded recently with findings that the company launched its product without having fully addressed known privacy issues. That investigation is a signal of where regulatory attention is heading, not an isolated case.

Then there is Quebec. Law 25 is fully in force, including the right to data portability that took effect in September 2024. It is enforced by Quebec’s Commission d’accès à l’information, with penalties of up to $10 million Canadian or two percent of global turnover, whichever is higher. Law 25 applies extraterritorially: any business that serves customers in Quebec or collects data from Quebec residents is in scope, regardless of where that business is headquartered.

Canada’s Privacy Commissioner, Philippe Dufresne, underscored this enforcement posture at the International Association of Privacy Professionals Canada Symposium in Toronto in May, where he announced new guidance on age assurance technologies and discussed the urgency of federal reform. The consistent message from regulators across the country has been that they are not waiting for new legislation before enforcing the obligations that already exist.

What This Signals for Canadian Businesses

The AI for All strategy reveals something beyond its specific legislative commitments. It signals that the federal government now treats AI governance as a matter of national sovereignty, not simply consumer protection. The language throughout the strategy around Canadian data, Canadian compute infrastructure, and Canadian oversight of AI systems is deliberate, and it reflects a broader anxiety about Canadian dependence on foreign cloud and AI infrastructure.

With no AI-specific statute currently in force following AIDA’s death alongside the rest of Bill C-27, organizations deploying AI in Canada in 2026 are navigating a patchwork of sector-specific guidance and general privacy law rather than a single clear standard. That patchwork is exactly what the incoming legislation is designed to replace. The practical question for any Canadian business using AI tools — whether that means a customer service chatbot, an internal productivity assistant, or a more sophisticated automated decision system — is whether governance work is happening now or will happen later under regulatory pressure.

From experience, the businesses that build privacy and AI governance structures proactively spend far less time and money than those that retrofit a program after an investigation or a customer complaint forces the issue.

What Canadian Businesses Should Do Now

The legislative landscape will keep shifting over the next year, and trying to predict the exact shape of the final bill is less useful than building the foundational practices that any version of the law will require.

Three actions matter most right now. First, every organization subject to PIPEDA needs a clearly designated individual accountable for privacy compliance. This is already a legal requirement, not a future one, and it is the first thing regulators ask about during any investigation.

Second, organizations using AI tools of any kind need a clear inventory of what personal data those tools touch, where that data is processed and stored, and whether vendor agreements reflect the organization’s obligations under Canadian privacy law. The OpenAI investigation is a useful illustration of how exposed even sophisticated technology companies can be when this groundwork has not been done.

Third, any business with customers or data subjects in Quebec should treat Law 25 as the practical floor for compliance today, not PIPEDA. Law 25 is stricter, fully in force, and being actively enforced with substantial penalties.

Bill C-27 may be dead, but the regulatory direction it represented is very much alive. The AI for All strategy makes that explicit. Businesses that spent the past year treating C-27’s death as a reason to wait are now working against a tighter timeline than they realize.

Related: What Shadow AI Is Doing to Canadian Businesses Right Now — how unsanctioned AI tools are creating PIPEDA exposure today, before any new legislation arrives.

Someone on your team is using an AI tool you did not approve.

They are pasting client emails into ChatGPT to get faster replies. Summarizing contracts with a free tool they found online. Running customer data through an app that saves them an hour every week. They are not doing it to cause problems. They are doing it because it works.

For small and medium-sized Canadian businesses without a dedicated IT or security team, this is happening right now, completely out of sight. That is Shadow AI, and it has become one of the fastest-growing data risks facing Canadian organizations today.

What Shadow AI Actually Means

Shadow AI refers to any artificial intelligence tool an employee uses without the knowledge or approval of the business. It follows the same pattern as Shadow IT — the long-standing problem of employees using personal apps and services for work purposes — but the scale and speed of AI adoption has made the risk significantly larger.

According to Verizon’s 2026 Data Breach Investigations Report, 15% of employees were classified as regular AI users on corporate devices in 2025. One year later, that figure reached 45%. That is a tripling in a single twelve-month window. A separate survey found that 66% of office professionals used AI tools despite believing it violated company policy.

For a business without anyone actively monitoring which tools are in use, that growth is completely invisible.

Where Business Data Is Actually Going

When an employee pastes client information into a free AI tool, that data leaves the organization’s environment. It travels to a server the business does not control, often located in another country, processed under terms of service the business owner has never read and almost certainly never agreed to on behalf of their clients.

The most common types of data employees feed into unsanctioned AI tools include customer information from sales and support teams, financial and legal documents including contracts, and internal business processes pasted in for help with a task.

For a law firm, that could be privileged client correspondence. For an accounting practice, it could be financial records. For a healthcare clinic, it could be patient information. In every one of those cases, the business remains legally responsible for what happens to that data, regardless of whether the owner knew it left the building.

The Canadian Compliance Exposure

Shadow AI is not just a security problem. For Canadian businesses, it is a legal one.

PIPEDA, Canada’s federal private sector privacy law, requires that personal information be protected regardless of where it is processed. If an employee sends client data to a US-based AI platform without the business’s knowledge, the organization may still bear legal responsibility if something goes wrong.

Quebec’s Law 25, which is fully in force and actively enforced, imposes stricter requirements. It mandates explicit consent for certain uses of personal data and places tighter restrictions around data transfers outside Quebec. Businesses that serve clients in Quebec are subject to these rules regardless of where the business itself is based.

IBM’s 2025 Cost of a Data Breach Report found that 20% of breached organizations were compromised through Shadow AI. When a breach involves a tool the business did not know existed, detection is slower and recovery is harder. For a small business without an incident response team, that gap can be the difference between surviving an incident and not.

This Is Not an Employee Problem

The instinct when reading this is often to frame it as a behaviour problem — employees using tools they should not be using, breaking the rules.

That framing misses the point.

From experience, employees turn to Shadow AI because the tools genuinely help them work faster and more effectively. If a business bans AI without offering an alternative, the problem does not go away. It just becomes invisible.

Research consistently shows a significant drop in unauthorized AI usage when approved alternatives are provided. The goal is not a crackdown. It is building a simple structure that gives employees a safe and sanctioned path to use these tools productively.

Three Steps Any Canadian Business Can Take This Week

These steps do not require a security team or a large budget. A business owner or office manager can action all three.

Start with a conversation, not a policy. Ask employees directly what AI tools they are using and what they are using them for. Frame it as a discovery exercise rather than a compliance audit. The answers will be more honest and the information more useful. Many business owners are surprised by what they find.

Draw a clear line around sensitive data. Before any formal policy exists, one simple rule closes a significant portion of the risk: client names, financial information, legal documents, and anything confidential should never go into an AI tool the business has not approved. Communicating that boundary clearly and consistently is a meaningful first step.

Write a one-page AI use policy. It does not need to be long or technical. It needs to answer three questions: which tools are approved, what types of data should never be entered into an AI prompt, and who to contact when someone is unsure. One page, shared with the team, is enough to establish accountability and reduce exposure.

Shadow AI is not a problem reserved for large organizations with complex systems. It is happening in Canadian businesses of every size, right now, through tools that may never appear in an IT audit. The organizations that get ahead of it are the ones that start the conversation before something goes wrong.

For enterprise security teams, the problem is larger in scale but identical in nature. The same starting point applies: find out what is in use, establish clear data boundaries, and give people a legitimate path forward.

Related: Canada’s Privacy and AI Reckoning — the regulatory landscape Shadow AI is operating in — and Your Firewall Is Fine. Your Employees Are the Problem. — why the human layer is always the first gap attackers find.

The security industry has a complicated relationship with AI right now. On one side, vendors are promising that machine learning will transform how organizations detect threats, prioritize vulnerabilities, and respond to incidents. On the other, practitioners who have lived through a few hype cycles are watching closely to see what actually holds up.

The honest answer is somewhere in the middle. AI has made meaningful contributions to both vulnerability management (VM) and incident response (IR). It has also given some organizations a false sense of progress while their foundational program gaps remain unaddressed.

Where AI Is Actually Delivering in Vulnerability Management and Incident Response

Vulnerability management used to be a largely periodic exercise. Scan, export, sort by CVSS score, patch what you can, repeat. The problem with that model is that it treats all critical vulnerabilities as equal and ignores the reality that exploitability depends heavily on context: network exposure, asset criticality, existing compensating controls, and active threat intelligence.

AI-driven VM platforms have made genuine progress here. Continuous attack surface monitoring means organizations now have dynamic visibility rather than a quarterly snapshot. Risk-based prioritization models factor in real-world exploitability, threat actor behavior, and business context, helping teams focus on the vulnerabilities that actually represent exposure rather than just high CVSS numbers. Correlation between internal asset data and external threat intelligence has also improved significantly, giving analysts context that used to take considerable manual effort to assemble.

On the IR side, the gains are equally concrete. AI-assisted triage has compressed the time between alert generation and meaningful investigation. Behavioral anomaly detection is catching lateral movement and credential abuse patterns that rule-based detection consistently missed. Automated containment on well-scoped playbooks can reduce dwell time in ways that simply were not possible with manual processes alone.

For security teams managing large environments with limited headcount, these capabilities are not optional enhancements. They are operationally significant.

Where the Fundamentals Still Carry the Weight

Here is where a more direct perspective is warranted: AI tools are force multipliers. That means they amplify what already exists. A well-run VM program with clean asset data, defined ownership, and consistent patch processes becomes faster and sharper with AI. A program built on incomplete inventory, unclear ownership, and inconsistent execution becomes faster at producing noise.

The fundamentals that AI cannot replace:

Asset inventory. This is the most unglamorous work in security and consistently the most neglected. If the CMDB is incomplete or stale, the attack surface is unknown regardless of what tool is scanning it. Every VM and IR program is only as good as the accuracy of what is in scope.

Defined severity tiers and escalation paths. During an active incident, ambiguity is expensive. Who declares a P1? Who calls legal? Who communicates to the board? These decisions should be made in advance, documented clearly, and practiced. No AI platform makes that decision under pressure.

Tabletop exercises. IR is a team capability, not an individual one. Runbooks only work if the people executing them have walked through the scenarios together. Teams that run regular tabletops respond measurably better when real incidents happen. The mechanics are familiar, the communication patterns are practiced, and the decision-making is faster.

Patch discipline. Risk-based prioritization is a meaningful improvement over blind CVSS sorting. But it requires organizational follow-through to mean anything. Reprioritization models fail when the underlying patch process is inconsistent or politically difficult to execute.

Runbook maintenance. Runbooks decay. Systems change, team members turn over, tools get replaced. A runbook that was accurate 18 months ago may contain broken escalation paths, outdated tool references, and contacts who no longer work at the organization. Regular review and validation is operational hygiene that AI-assisted detection cannot compensate for.

The Risk of Dashboard Confidence in AI-Powered Security Programs

The scenario that concerns practitioners most is what could be described as dashboard confidence: an organization that has modern, well-integrated security tooling, reasonable metric trends, and a general sense that the program is mature, but has never pressure-tested whether it would actually hold under real incident conditions.

AI platforms are good at producing dashboards. They are not good at flagging that the escalation chain has never been tested, that the regulatory notification timeline is unclear, or that the IR team has never executed a real containment together. Those gaps only surface when something breaks.

Regulatory obligations deserve particular attention. Depending on the sector and jurisdiction, a confirmed breach may trigger mandatory notification timelines measured in hours or days. AI can help detect and scope an incident faster. It cannot draft a regulatory communication, make legal determinations about reportability, or manage crisis communications with affected parties. Those require human judgment, defined process, and in many cases legal counsel involvement that should be scoped before an incident, not during one.

The Right Mental Model for AI in Security

The most useful framing for AI in security is this: think of it as a senior analyst operating at machine speed. It can surface patterns, triage signals, prioritize work, and accelerate response. What it cannot do is compensate for a program that was built on shaky foundations.

Organizations that get the most value from AI-powered VM and IR tools are the ones that already had reasonable fundamentals in place before they adopted them. They knew their assets. Their runbooks were current. Their escalation paths were practiced. AI made those programs meaningfully better.

The organizations struggling are the ones that adopted AI tooling as a substitute for program discipline rather than an extension of it.

A useful self-assessment: if the AI layer was removed from a security program tomorrow, how would the team perform? If that question is uncomfortable, the next investment priority is probably not another platform. It is the process work that was deferred to make room for it.

The basics are not new. They are not exciting. But they are consistently what separates organizations that manage incidents well from organizations that get managed by them.

Related: Why Your DR Plan May Fail When You Need It Most — the same discipline gaps that weaken IR programs also show up in disaster recovery — and Your Business Isn’t Too Small to Be Hacked for the SMB lens on these same risks.

Anthropic this week announced two significant security features for its Claude Code platform: a real-time security-guidance plugin and a self-hosted sandbox environment. The announcements, made at the company’s Code w/ Claude event in London, mark a meaningful expansion of AI-assisted security tooling directly into the developer workflow. For application security teams, the release raises both opportunities and important questions about where AI fits in a mature security program.

What Anthropic Announced: The Security Plugin and Self-Hosted Sandbox

The security-guidance plugin is available to all Claude Code users at no additional cost and can be installed through the built-in plugin marketplace. Once active, it operates automatically across three stages of development.

At the file edit stage, the plugin runs a fast, deterministic pattern match with no AI model call, flagging dangerous code constructs such as eval(), os.system(), child_process.exec(), and DOM injection vectors. Because this layer requires no inference, it adds no usage cost to the developer.

After AI-generated changes are made during a coding session, a second review pass examines the full diff and surrounding context to catch vulnerabilities introduced by the model itself. This is a notable design decision: the system audits its own output rather than assuming AI-generated code is safe.

At commit time, a deeper agentic review reads surrounding callers, sanitizers, and related files to reduce false positives before code is pushed. The combined approach targets approximately 25 high-risk vulnerability classes including:

• SQL injection
• Command injection
• Cross-site scripting (XSS)
• Hardcoded credentials and API keys
• Insecure deserialization
• Improper input validation

Anthropic reports that internal use of the plugin produced a 30 to 40 percent reduction in security-related pull request comments, suggesting meaningful improvement in code quality at the point of creation.

The Self-Hosted Sandbox

The self-hosted sandbox, currently in public beta, allows Claude Managed Agents to operate within a user-controlled environment connected to private MCP servers. Tool execution runs on the organization’s own infrastructure or through providers such as Cloudflare, Daytona, Modal, or Vercel, while Anthropic’s infrastructure handles orchestration and context management. The practical result is that sensitive files, repositories, and data remain within the organization’s network perimeter, subject to its own audit logging and security policies.

The Claude Code Security Initiative: Broader Context

The security-guidance plugin is part of Anthropic’s larger Claude Code Security initiative, which launched as a research preview in February 2026 and expanded to an Enterprise public beta in late April 2026. The broader platform goes beyond regex-based pattern matching, using advanced AI reasoning to conduct codebase-wide scans that trace data flows across files, run adversarial verification passes on findings, and propose targeted patches for human review. Anthropic has reported the system identified over 500 previously unknown high-severity vulnerabilities in open-source codebases during internal testing.

What This Means for Application Security Programs and AppSec Teams

The value of this tooling is real and should not be dismissed. Catching injection flaws, hardcoded secrets, and insecure API usage at the moment of creation is substantially better than discovering them during code review, penetration testing, or after a breach. Shifting security left has long been a goal of mature AppSec programs, and AI-assisted tooling at this layer is a credible step toward that goal.

However, security teams should be clear-eyed about what the plugin does not address.

Pattern-based vulnerability detection, however well implemented, operates on known categories of risk. It cannot perform threat modeling, assess architectural decisions, or reason about how a combination of individually minor issues might be chained into a significant attack path. It does not replace penetration testing, red team exercises, or the adversarial thinking that experienced security practitioners bring to a program.

Regulated environments will also need to evaluate how the plugin and sandbox fit within existing compliance requirements. The self-hosted sandbox addresses some data residency concerns, but organizations should assess the tooling against their specific control frameworks before broad deployment.

The most productive framing for security leaders is to treat the plugin as a force multiplier rather than a substitute. It raises the baseline quality of code entering the pipeline and reduces low-signal noise in security review. That creates capacity for security teams to focus on higher-judgment work: architecture reviews, threat modeling, incident response, and adversarial testing that no automated tool can replicate.

Getting Started

The security-guidance plugin is available now for all Claude Code users. Installation is handled through the /plugins command within Claude Code. The self-hosted sandbox is available in public beta. Organizations interested in the broader Claude Code Security platform, including deep codebase scanning and enterprise controls, can access it through Anthropic’s Enterprise tier.

The Bottom Line

Security tools reduce mistakes. Security professionals reduce risk. The organizations that understand the difference will benefit the most from AI-assisted development.

Related: The Rise of AI-Assisted Attacks: What Security Teams Need to Know — the threat context that makes tools like this necessary — and our Code Review service for teams that want a human expert behind the AI scan.

There is a technology myth that persists in boardrooms and budget meetings across every industry: that cybersecurity is fundamentally a technology problem. Buy the right firewall. Deploy the right antivirus. Subscribe to the right threat monitoring service. Problem solved.

It is not solved. Not even close.

The most sophisticated security stack in the world will not protect an organization whose employees do not know how to spot a phishing email. And the data is unambiguous on this point. Ninety-five percent of successful cyberattacks involve human error as a contributing factor. Not a software vulnerability. Not a misconfigured server. A person making a decision they were not equipped to make safely.

This is the gap that attackers exploit most reliably, most profitably, and most often.

The Human Layer Is the Weakest Link

Every organization has layers of defense. Firewalls, endpoint protection, email filtering, multi-factor authentication. Security teams invest significantly in these controls, and for good reason. They work.

But every one of those technical controls has a human being sitting behind it. And humans can be manipulated in ways that technology cannot.

A phishing email that bypasses every filter still needs a person to click it. A fraudulent wire transfer request still needs a person to authorize it. A credential harvesting page still needs a person to type their password into it. The attacker does not need to break through the technology. They need to convince one person to open a door.

What This Looks Like in Practice

Security awareness assessments conducted across organizations of varying sizes consistently surface the same patterns.

Employees receive phishing simulation emails and click them at rates that would surprise most executives. Not because those employees are careless or unintelligent, but because modern phishing attempts are sophisticated, personalized, and designed by people who study human psychology professionally.

Password hygiene remains a persistent problem. Employees reuse passwords across personal and professional accounts. They share credentials with colleagues for convenience. They use passwords that are technically compliant with policy but trivially guessable in practice.

Social engineering extends beyond email. Attackers call help desks impersonating employees and request password resets. They send text messages impersonating executives with urgent payment requests. They exploit the natural human instinct to be helpful, to avoid conflict, and to respond to authority.

In each of these scenarios, the technical controls are largely irrelevant. The human being is the attack surface.

Why Training Alone Is Not Enough

Many organizations respond to this reality by deploying annual security awareness training. A one-hour module, a completion certificate, a checkbox on the compliance audit.

This approach is better than nothing. It is not enough.

Research consistently shows that security awareness training produces measurable behavior change only when it is ongoing, scenario-based, and reinforced regularly. A single annual module does not build instinct. It builds familiarity with a module.

Effective security awareness programs treat the human layer with the same rigor applied to technical controls. They run simulated phishing campaigns throughout the year. They provide immediate, contextual feedback when an employee clicks something they should not have. They create a culture where reporting suspicious activity is encouraged and rewarded rather than stigmatized.

The goal is not compliance. The goal is behavior change at the individual level, sustained over time.

What Organizations Should Actually Do

Building a resilient human layer does not require an enormous budget. It requires consistency and the right approach.

• Run phishing simulations regularly. Not once a year. Quarterly at minimum, with varied scenarios that reflect current attack trends. Employees who are regularly tested develop sharper instincts than those who encounter a simulation once and forget about it.
• Make reporting easy and consequence-free. One of the most damaging dynamics in organizational security is the culture of blame. When employees fear consequences for clicking a phishing link, they stop reporting incidents. Unreported incidents become uncontained breaches. Create an environment where reporting is the expected and valued response.
• Tailor training to role and risk level. The threats facing a finance team are different from those facing a customer service team. Generic training produces generic awareness. Role-specific training produces relevant behavior change.
• Extend awareness beyond email. Train employees to recognize vishing, smishing, and in-person social engineering attempts. The attack surface is not limited to the inbox.
• Measure and iterate. Track click rates on phishing simulations over time. Measure reporting rates. Identify which teams or individuals need additional support. Treat human awareness as a metric, not a checkbox.

The Bottom Line

Technology will continue to improve. Attackers will continue to adapt. The one constant in this equation is the human being making decisions under pressure, with incomplete information, in an environment designed to manipulate them.

Organizations that invest in their human layer with the same seriousness they apply to their technical controls will be meaningfully more resilient than those that do not. The firewall matters. The person sitting behind it matters more.

Related: The Rise of AI-Assisted Attacks — why AI has made phishing dramatically harder to detect — and Identity Is No Longer an IT Problem for what strong MFA and access controls actually look like in practice.

AI adoption is accelerating faster than most organizations can govern it. And identity security is where that gap becomes dangerous.

That was not just a talking point at the Okta AI Identity Summit in Toronto last week. It was the thread running through every session, every panel, and every conversation in the room. The organizations leading on AI are not simply moving fast. They are building identity as the foundation first, and everything else on top of it.

The question is no longer whether AI will change how organizations operate. It already has. The question is whether identity infrastructure can keep pace with the speed at which AI is being adopted, and what happens to the organizations where it cannot.

The Three Questions Most Organizations Cannot Answer

Every organization deploying AI agents — whether for automation, decision support, or customer interaction — should be able to answer three questions clearly and immediately.

Where are your AI agents operating? This sounds straightforward. In practice, many organizations have AI tools running across multiple departments, deployed by different teams, with no centralized visibility into what those agents are doing or where they are active.

What systems and data can they access? AI agents that can query databases, send communications, process transactions, or interact with third-party systems carry real access risk. If that access has not been explicitly scoped and governed, the organization does not have an AI problem. It has an identity problem wearing an AI mask.

Who is accountable when they act autonomously? This is the question that tends to produce the longest silence. When an AI agent makes a decision that results in a data exposure, an unauthorized transaction, or a compliance violation, accountability cannot be an afterthought. It needs to be designed into the governance model from the beginning.

Most organizations cannot answer all three questions confidently. That is not a technology gap. It is a governance gap. And it does not get smaller as AI scales. It gets larger.

Why Identity Has Become a Strategic Control

For most of the history of enterprise IT, identity and access management lived in the back office. It was an IT function — necessary, largely invisible, and rarely discussed at the executive level unless something went wrong.

That positioning is no longer appropriate for the environment organizations are operating in today.

When AI agents are acting on behalf of the organization — making decisions, accessing systems, and interacting with data autonomously — identity is the mechanism that determines what they can do and what they cannot. It is the line between a well-governed AI deployment and an ungoverned one.

The organizations at the summit that are ahead of this problem share a common characteristic. They have elevated identity from an operational IT concern to a strategic business control. Their identity programs are not reactive. They are built to scale ahead of adoption, not scramble to catch up after it.

That shift in positioning — from back-office function to strategic foundation — is what separates organizations that will navigate AI governance well from those that will not.

What Zero Trust Has to Do With It

Zero Trust as a framework has been discussed extensively in security circles for years. In the context of AI agents, it takes on renewed practical relevance.

The core principle of Zero Trust is that no user, device, or system should be trusted by default, regardless of where it sits relative to the network perimeter. Every access request should be verified, every time, based on identity and context.

Applied to AI agents, this means every agent should have a defined identity. Every action that agent takes should be logged and attributable. Access should be granted on a least-privilege basis, scoped precisely to what the agent needs to perform its function and nothing beyond that.

This is not a theoretical framework for future consideration. Organizations deploying AI agents today without this governance model in place are accumulating risk with every deployment.

The Governance Gap Is the Real Risk

The conversation at the summit kept returning to the same underlying tension. AI adoption is being driven by business units, by product teams, by leadership mandates to move faster and do more with less. Identity governance is being driven by security and IT teams who are, in many cases, finding out about AI deployments after the fact.

That gap — between the speed of adoption and the maturity of governance — is where the real risk lives.

It is not that AI is inherently dangerous. It is that AI without identity governance is ungoverned. And ungoverned access, whether human or machine, is the foundation of most significant security incidents.

The organizations that will have a competitive advantage as AI matures are not necessarily the ones moving fastest. They are the ones building the governance infrastructure to move fast safely. Identity is that infrastructure.

Where to Start

For organizations looking to close the governance gap, the starting point is visibility. Before any controls can be implemented, there needs to be a clear picture of what AI agents are deployed, what access they have been granted, and what activity they are generating.

From there, the work is familiar to anyone who has run an identity program: define roles and access scopes, implement least privilege, establish logging and monitoring, and assign accountability clearly.

The difference in the AI context is the urgency. Every week that passes without this governance in place is a week of compounding exposure. The conversation is just getting started. The time to build the foundation is now.

Related: Zero Trust Is Not a Product — It’s a Strategy — identity is the control plane Zero Trust is built on — and The Rise of AI-Assisted Attacks for why identity is increasingly the primary attack surface.

There is a persistent and dangerous myth circulating among small business owners: that cybercriminals only target large organizations. Banks. Hospitals. Multinational corporations. The reality, as security professionals see it in practice, is far less forgiving.

Small and mid-sized businesses are not beneath the notice of attackers. In many cases, they are the preferred target, precisely because their defenses are weaker, their response capabilities are limited, and the path of least resistance runs straight through them.

The statistics bear this out. Nearly 60% of small businesses that experience a significant cyberattack close within six months. Not because the attack was uniquely sophisticated, but because the aftermath — the downtime, the recovery costs, the reputational damage, and the regulatory exposure — is more than most small operations can absorb.

The Assumption That Gets Businesses Breached

The most common gap that surfaces in security risk assessments is not a technical one. It is a mindset one.

Business owners who have never experienced a breach often operate under the assumption that their size makes them invisible. That assumption is wrong, and it is becoming more wrong every year.

Automated scanning tools — the same kind used by security researchers and malicious actors alike — sweep the internet continuously. They do not distinguish between a Fortune 500 company and a ten-person accounting firm. They look for open doors. And when they find one, they walk through it.

The businesses most at risk are not necessarily the least informed. They are often simply the ones who kept pushing the question of security to the next quarter, the next budget cycle, the next year.

What the Gaps Actually Look Like

Risk assessments conducted across small and mid-sized organizations consistently surface the same categories of exposure, regardless of industry.

• Access management is almost always underdeveloped. Employees who left the company months ago may still have active credentials. Shared passwords are common. There is rarely a clear picture of who has access to what and why.
• Patch management is another consistent weak point. Known vulnerabilities in operating systems, software, and network devices go unaddressed for months, sometimes years. These are not zero-day exploits. They are published, documented vulnerabilities with freely available exploit code.
• Backup and recovery processes, where they exist, are frequently untested. A backup that has never been restored is not a recovery plan. It is a file. Organizations discover this distinction at the worst possible moment.
• Human awareness remains the most exploited entry point across every sector. Staff who have not received regular, practical security training are significantly more likely to click a phishing link, hand over credentials, or authorize a fraudulent payment. This is not a failure of intelligence. It is a failure of preparation.

The Cost of Doing Nothing

Each of the gaps described above is addressable. None of them require enterprise budgets or dedicated security teams. What they require is awareness, prioritization, and a structured approach to identifying which risks matter most for a given organization.

The cost of not addressing them, however, can be terminal. Ransomware payments. Regulatory fines. Lost client contracts following a data breach notification. The reputational damage of being the business that got hacked. For many small organizations, any one of these outcomes is enough to force closure.

Where to Start

The most effective starting point for any small or mid-sized business is a structured risk assessment. Not a generic checklist downloaded from the internet, but an honest evaluation of the specific environment: the systems in use, the people who use them, the vendors with access, and the processes that hold it all together.

A proper risk assessment does not just identify problems. It prioritizes them, explains their business impact in plain language, and provides a clear path forward.

For business owners who have been putting this conversation off, the right time to have it is before an incident. Not after.

Related: Why Your DR Plan May Fail When You Need It Most — a deeper look at the backup and recovery gaps that leave businesses unable to recover — and take the free SMB Security Scorecard to see where you stand across 7 categories in 2 minutes.

The threat landscape has shifted — and most small businesses haven’t gotten the memo.

We’ve been conducting risk assessments across organizations of different sizes for several years. In the last 12 to 18 months, something has changed. The attacks we’re seeing evidence of aren’t just more frequent — they’re fundamentally smarter. And the reason is straightforward: attackers now have access to the same AI tools that the rest of us use every day.

This isn’t a distant, enterprise-level problem. It’s showing up in the assessments we run on small and mid-sized businesses right now.

What AI-Powered Attacks Actually Look Like

To be specific — “AI-powered attacks” can sound abstract.

Phishing has always been the most common entry point — it still is. But AI has removed the tells we used to rely on. Bad grammar, awkward phrasing, generic greetings — gone. Attackers now use large language models to generate personalized, perfectly written emails that reference your company name, your CEO’s writing style, even recent news about your business.

Then there’s voice cloning and deepfakes. This isn’t science fiction. Scammers are using AI-generated audio to impersonate executives and authorize fraudulent wire transfers. A CFO gets a voicemail that sounds exactly like the CEO asking them to process an urgent payment. That call never happened.

Finally, reconnaissance is now automated. Finding your exposed ports, checking for unpatched systems, identifying which of your employees reused passwords — attackers can run these scans in minutes. What used to take days of manual work now happens before your morning coffee.

Why SMBs Are Especially Vulnerable

There’s a common assumption that cybercriminals focus on large corporations. It’s wrong.

Small and mid-sized businesses are often seen as easier targets precisely because their defenses haven’t kept pace. Many are still running security playbooks built for threats from five years ago. And when a breach happens, the impact can be devastating — nearly 60% of small businesses that suffer a major cyberattack close within six months.

The resource gap is real. But the answer isn’t to spend more. It’s to spend smarter and close the right gaps first.

What You Should Actually Do

Based on what we see in risk assessments, here are the highest-impact steps that make a real difference:

• Train your people — consistently. Not a one-time onboarding module. Regular, scenario-based security awareness training. Ninety-five percent of breaches involve human error. AI makes those human moments harder to catch, so your team needs to be sharper.
• Move to phishing-resistant MFA. Standard SMS-based authentication is no longer sufficient. Passkeys and hardware security keys are significantly harder for attackers to bypass, even with AI-generated phishing pages.
• Build a financial verification protocol. Any request involving a wire transfer, payment change, or sensitive authorization should require a secondary verbal confirmation — a quick call to a known number, not a reply to the email. This single control has prevented countless business email compromise attacks.
• Know where your real gaps are. This is where a proper risk assessment becomes invaluable. Not a generic checklist, but an honest look at your specific environment — your systems, your people, your vendors, your processes. You can’t defend what you don’t know is exposed.

The Bottom Line

The same AI tools making attackers faster and more convincing are also available to defenders. But the window to close that gap doesn’t stay open forever.

If you’re a business owner or leader wondering whether your current defenses are still fit for purpose, that’s the right question to be asking — and the right time to get an answer.

Related: The Rise of AI-Assisted Attacks: What Security Teams Need to Know — an earlier deep dive on the same AI threat landscape — and Your Firewall Is Fine. Your Employees Are the Problem. for why phishing succeeds even when defenses are in place.

The security community has spent years talking about what the next generation of threats would look like. A lot of us assumed AI would help defenders more than attackers first. The reality is messier than that. From nation-state groups to ransomware operators, attackers are already using AI tools as part of how they work.

How Attackers Are Using AI Today

The most immediate impact is in social engineering. Phishing emails that used to have obvious grammar mistakes now look like they came from a real person in your company. AI lets attackers write convincing, personalized emails at scale, tailored to your industry, your role, even your writing style if they've scraped your LinkedIn.

Beyond phishing, AI is being used to:

• Accelerate reconnaissance — automated tools can ingest large amounts of OSINT data and surface actionable targets faster than any human analyst.
• Generate polymorphic malware — code that rewrites itself to evade signature-based detection, a task that once required significant skill but is now more accessible.
• Craft deepfake audio and video — used in BEC and executive impersonation attacks. Several high-profile cases in 2024 involved AI-generated voice calls impersonating CFOs.
• Automate vulnerability chaining — AI models can reason across known CVEs to identify exploit chains that human attackers might miss.

What Defenders Should Be Doing Right Now

• Retrain your phishing awareness programs. The old "look for spelling mistakes" heuristic is dead. Focus on security awareness training that teaches users to verify requests through out-of-band channels, especially for financial transactions or credential changes.
• Invest in behavioral detection. Signature-based controls alone won't catch AI-generated malware. EDR solutions with strong behavioral analytics become critical.
• Tighten identity controls. AI-assisted attacks often succeed at the initial access stage. MFA implementation, phishing-resistant credentials (FIDO2), and conditional access policies reduce the blast radius significantly.
• Treat AI as a defender's tool too. SIEM platforms and UEBA solutions are incorporating AI-driven anomaly detection. The NIST AI Risk Management Framework also provides guidance on managing AI risks across your organization. Make sure your team knows how to tune and trust these signals without alert fatigue.
• Conduct tabletop exercises that include AI scenarios. Test your incident response against a deepfake BEC or AI-assisted credential stuffing campaign before the real thing happens.

The Bottom Line

AI hasn't changed what attackers are after. They still want access, money, or disruption. What it has changed is the speed, scale, and quality with which they go after it. Security teams that update how they detect, train, and respond will be in a much better spot than those still using the same playbooks from five years ago.

Related: Hackers Are Using AI. Is Your Business Keeping Up? — the same threat landscape through an SMB lens, with the highest-impact steps to take right now.