Where Does AI Risk Live in Your Stack?

Most AI security plans I've reviewed in the past year share the same structural gap: they describe policies, not architecture. They'll tell you who's allowed to use which tools, what data classifications apply, and which vendor certifications to require. What they won't tell you is where risk actually concentrates once those tools are running inside your environment; at the application layer, in your identity architecture, and across data flows that your policy documents often misalign with.

A policy that says "employees must not paste sensitive data into AI tools" does nothing about the AI summarization feature your enterprise platform vendor just enabled by default. A vendor checklist that confirms SOC 2 compliance doesn't tell you whether that vendor's model is ingesting third-party content at runtime that your security team has never evaluated.

To make matters worse, rarely are these policies codified end-to-end to disable potential harm to the organization.

The argument I want to make here is straightforward, AI security is an architecture decision. Policies are one layer of an ecosystem that needs to align with business needs. If your plan stops at the policy layer, you've covered roughly 20% of the actual surface area. Let me walk through what the other 80% looks like.

Know What You're Actually Protecting

Before you can secure AI in your environment, you need to separate two categories of exposure that most organizations lump together.

The first is current workflow automation, this includes the AI features already embedded in tools you own. Summarization in your email client. Copilot suggestions in your IDE. AI-powered search in your knowledge management platform. These features arrived inside products your team had already approved, which means they often bypassed the procurement scrutiny you would apply to a new standalone AI tool. They create risk inside systems you believed were already secured.

This exposure is already being exploited. Microsoft confirmed that 31 organizations across 14 industries have been targeted through AI recommendation poisoning. These are attacks that manipulate what AI summarization features surface to users. The tools that organizations deployed to save time reading documents became a vector for feeding those organizations manipulated information. For Canadian financial institutions operating under OSFI's B-13 guideline, the question is whether these embedded AI features fall under your existing third-party risk management obligations. I won't keep you waiting on the answer, yes they do.

The second category is new competitive capabilities - agentic workflows, multi-agent orchestration, AI-driven credit decisioning, automated compliance monitoring. These are systems your organization is building or buying to do things it couldn't do before. The risk profile is fundamentally different because you're introducing new autonomous actors into your environment, new data flows, new integration points.

Table 1: Policy vs. Architecture Coverage

Policies tend to treat both categories identically: an acceptable use policy, a data classification rule, a vendor assessment. Architecture can't afford that shortcut. The threat model for a copilot embedded in your email is different from the threat model for an autonomous agent processing loan applications. The controls need to reflect that difference.

Three Layers Where Risk Concentrates

Once you've separated what you're protecting, the next question is where risk actually sits. It's concentrated in three layers that most policy-driven plans either underestimate or miss entirely.

The Application Layer

AI features embedded in enterprise tools create a class of runtime dependency that traditional security architectures weren't designed for. When your platform's "Summarize with AI" button queries an external model that ingests third-party content at the moment a user clicks it, your WAF and network segmentation provide no protection against what that model surfaces. The content it summarizes may have been poisoned upstream, and your security stack has no visibility into that pipeline.

Shadow AI compounds this. Teams across the organization adopt AI tools without IT's knowledge including browser extensions, SaaS add-ons, API integrations wired up by a developer who needed to ship faster.

Your application-layer attack surface is almost certainly larger than any inventory your security team maintains, because the tools that expanded it didn't go through the front door.

Identity and Access Architecture

This is where the gap between policy and architecture becomes most visible and where a single, centralized AI system deployed across the enterprise can quietly dismantle your security posture. It's the reason why Zero Trust architecture (ie. build the system so it validates at each point, trust isn't inherent) in no longer optional.

Consider what happens when an organization deploys one general-purpose AI platform with broad access across departments. That system now moves across east-west traffic between internal services and north-south traffic between your environment and external endpoints. It has visibility into multiple workloads simultaneously. It can access data spanning business units, classification levels, and regulatory jurisdictions. A single AI system with that reach breaks the foundational zero trust principle of least privilege by design.

The identity problem goes deeper. Agentic workflows and multi-agent architectures expand the attack surface non-linearly: each autonomous agent is both a potential entry point and a lateral movement vector. Agents communicate across API boundaries, share context, and invoke tools or external services autonomously. They create trust chain vulnerabilities that traditional IAM and network segmentation weren't designed to catch. As agents can mimic legitimate user behaviour such as making API calls, accessing files, querying databases in patterns that resemble normal human workflows, your existing anomaly detection and access control processes may not flag them. This is amplified in environments with edge devices such as IoT systems, many of which will have smaller local models running.

You're relying on controls built to distinguish between authorized and unauthorized humans, and applying them to autonomous systems that don't behave like either.

Then there's the logging gap. When an agent accesses PII or sensitive data during a workflow, who logs that access? Under what identity? With what audit trail? Most organizations don't have answers to those questions because their access logging was designed for human-initiated sessions, not autonomous agent chains that may traverse half a dozen systems in a single operation.

Data Flows

Where does your AI training data reside? Who has access? Can your vendor reuse your operational data to train their own models? These aren't policy questions, they're architecture questions with direct regulatory implications.

Data that gets statistically embedded in a model persists beyond your normal retention periods. You can delete a record from your database, but if that record was part of a training dataset, its patterns may live on in model weights you don't control. For Canadian organizations subject to PIPEDA and provincial privacy legislation, this creates a retention and deletion problem that policy language alone cannot solve.

If you are building internal AI systems in a regulated industry, EU AI Act and future Canadian regulations will require insists into model training, biases, etc. For organizations that fall under critical infrastructure, these will be imperative to prove and you need to plan as such.

The sovereignty angle is unavoidable. If your AI vendor routes data through US infrastructure, your data governance posture may be weaker than your policy documents claim. TD's AI Prism rollout through Microsoft systems is illustrative: enterprise scale AI adoption with legitimate questions about where data is housed, what leaves Canada, and what strategic intellectual property is at risk. This isn't a critique of TD specifically, it's the set of questions every regulated Canadian organization needs to be asking and that most AI security plans don't address architecturally.

The uncomfortable conclusion from these three layers is that your vendors' own AI integrations may represent your largest unexamined exposure. Which leads to a question that policy-driven plans rarely ask.

Your Vendors Are Expanding Your Attack Surface

Third-party AI features are a first-order procurement and architecture concern, and most organizations are still treating them as a checkbox exercise.

AI recommendation poisoning isn't theoretical, off-the-shelf tools make it accessible enough that Microsoft documented it happening across 14 industries. The attack doesn't require compromising the vendor. It requires manipulating the content that the vendor's AI ingests at runtime, which may be entirely outside the vendor's control. Your vendor can pass every security certification you require and still serve you poisoned summaries because the vulnerability isn't in their platform, it's in the content pipeline their AI consumes.

For Canadian financial institutions, this has specific regulatory weight. OSFI's B-13 guideline on technology and cyber security establishes third-party risk management obligations. AI features embedded in core banking or wealth management platforms likely fall under those obligations, and procurement teams should be adding AI-specific questions to their vendor risk assessments: Does your AI feature ingest content from external sources at runtime? Can we disable AI features independently of the core product? Will you notify us when AI produces unsafe or misleading outputs? Can you confirm that our operational data is not reused for model training?

Your software bill of materials needs to extend to AI components. Where are models hosted? What data flows exist between your environment and the vendor's AI infrastructure? Can you control whether AI features operate in an offline or sandboxed mode? If your vendor can't answer these questions with architectural specifics, not marketing assurances, that relationship needs to re-evaluated.

Architecture Has Layers

The onion metaphor my notes keep coming back to is apt. A real AI security architecture has layers, and each one depends on the one beneath it.

Digital Operating Model

Does your AI adoption align with your strategic objectives, or is it reactive? You don't want teams grabbing tools because competitors announced something similar. The operating model layer forces a question that policy skips: which AI capabilities are competitive investments that justify new architectural commitments, and which are operational tools that should slot into existing controls? Getting this wrong means either over engineering controls for low risk features or under engineering them for systems that carry real competitive and regulatory exposure.

Governance

Governance matters. But governance that stops at usage policies misses the harder work: maintaining an AI asset inventory that includes shadow AI, conducting risk and impact assessments tied to defined risk tiers, scaling human oversight requirements to the risk level of each system, and establishing accountability structures that don't depend on vendor self-governance.

The EU AI Act's four risk tiers (unacceptable, high, limited, and minimal) provide the most mature framework available for this classification work. Even without Canadian equivalents in law today, using those tiers to categorize your AI workloads forces architectural decisions that acceptable use policies never touch. An AI system classified as high risk under that framework (credit decisioning, biometric identification, critical infrastructure operations) demands a different governance posture than a meeting summarization tool classified as limited risk.

Self-governance by AI vendors has proven unreliable. The OpenAI board upheaval demonstrated how quickly organizational commitments to safety can be overridden by commercial pressure. Anthropic's evolving relationship with the US Department of Defense shows that even companies with stronger safety positions are subject to external pressure that changes their posture. For Canadian regulated industries, building on platforms governed solely by the priorities of US headquartered companies is a design choice with consequences. Co-regulation where statutory requirements set the floor and industry participation raises it is the direction this needs to head.

Regulatory Compliance

OSFI B-13, Bill C-26 (the Critical Cyber Systems Protection Act), C-8, Canada's voluntary code of conduct for generative AI, and provincial privacy legislation all create obligations that intersect with AI adoption. The EU AI Act serves as a leading indicator of where Canadian regulation will likely move.

Table 2: AI Risk Tiers for Regulated Industries

Based on the EU AI Act's four-tier classification, applied to common use cases in Canadian financial services and energy sectors.

The traditional lens of governance, risk, and compliance won't keep pace with digital transformation timelines. Open banking deadlines are a current proof point: organizations that treated regulatory compliance as a periodic exercise rather than an architectural capability are scrambling. AI regulation will follow the same pattern. The organizations that embedded compliance into their architecture such as automated validation, policy-as-code, continuous monitoring will adapt. Those that relied on manual processes and periodic audits will fall behind.

Security Controls

Zero trust across all five domains — identity, device, network, workloads, and data — applied specifically to AI workloads. This is where the architectural argument becomes concrete.

Encryption and access controls need to extend to every AI interaction. Data in transit between your environment and AI services, data at rest in model training sets, data in use during inference each state requires encryption controls that eliminate unauthorized access. Access controls should enforce least privilege at a granular level: which users, which agents, which workflows can access which data through which AI systems.

No agent should operate with unlimited access. Just-in-Time (JIT) access provisioning ensures that agents and AI systems receive elevated permissions only when needed and only for the duration of a specific task. Just-Enough-Access (JEA) ensures those permissions are scoped to the minimum required for that task. Every elevation, every access event, every data interaction by an AI agent needs to be logged with the same rigour you'd apply to a privileged human administrator because the blast radius of a compromised agent with standing access is at least as large.

Threat modeling should incorporate MITRE ATT&CK alongside MITRE ATLAS, which extends the threat framework specifically to AI and machine learning systems. Remote browser isolation for AI interfaces handling sensitive data prevents PII from leaking upstream. And for organizations deploying AI in OT environments, human-in-the-loop requirements should be non-negotiable for any system where AI outputs could affect safety.

Integrations and Scalability

AI deployed alongside IoT, operational technology, or multi-cloud environments expands the risk footprint non-linearly. Each integration creates compounding effects: an AI agent that can access both your cloud workloads and your OT network doesn't represent two risks added together; it represents a multiplication of lateral movement paths, data exposure scenarios, and trust-chain vulnerabilities.

Architecture needs to account for these compounding effects rather than treating each integration as an isolated risk. A sandbox approach testing AI systems in controlled environments scaled to their risk tier before production deployment provides a structured way to evaluate these interactions. The EU has already piloted regulatory sandboxes for AI; Canadian organizations can apply the same principle internally even without a regulatory mandate.

The 20% Problem

Each of these five layers depends on the one beneath it. Governance without the right operating model produces policies disconnected from strategic reality. Security controls without governance lack the risk classification to know where to apply them. Regulatory compliance without security controls is documentation without enforcement.

Policies sit at the governance layer. An AI security plan that covers only that layer addresses roughly 20% of the actual attack surface. The other 80% lives in architecture decisions: how your identity system handles autonomous agents, how your data flows are governed at runtime, how your vendor integrations are isolated and monitored, how your controls compound as integrations multiply.

The organizations that will handle this well share a common trait: they treat AI security as an architecture discipline that starts at the operating model and works outward through every layer, rather than a policy exercise that starts at governance and stops there.

If your current AI security plan reads more like a policy document than an architecture document, the first step is understanding what it doesn't cover. The gap between those two documents is where your actual risk lives.