This paper provides general research and architecture analysis. It is not a certification, regulatory determination, legal opinion, penetration-test authorization or system-specific security assessment.
Executive perspective
Enterprise AI is moving from applications that generate content toward systems that retrieve sensitive information, call tools, execute code, interact with APIs and initiate business actions. This increases the importance of conventional security controls while creating new questions about machine identity, model behaviour, instruction integrity and runtime authority.
The strongest approach is not to create a separate AI-security universe. It is to extend identity, data security, application security, software supply-chain assurance, monitoring and incident response into the AI execution layer, then add controls for model-specific behaviour and agentic actions.
AI systems inherit the enterprise attack surface
A model may be the visible component, but the surrounding system includes prompts, retrieval stores, APIs, secrets, plugins, cloud infrastructure, vector databases, orchestration logic, third-party models and user identities. Compromise can occur at any of those layers.
Security architecture should therefore document the end-to-end data and action path: what enters the model, which sources it can retrieve, which tools it can call, which credentials it uses, where outputs go, and which actions can affect customers, employees, systems or money.
Treat AI agents as first-class identities
Agentic systems may perform repeated actions at machine speed, which makes shared credentials and broad service accounts especially dangerous. Each agent or agent class should have an attributable identity, bounded authority, lifecycle owner and auditable relationship to the human or business process it serves.
Permissions should be scoped to task, environment and time. High-impact actions can require step-up authorization, policy evaluation, transaction limits or human approval. Revocation should be immediate and should not depend on editing prompts or waiting for an application deployment.
Protect the instruction, retrieval and knowledge layers
System prompts, tool descriptions, policies, retrieval corpora and orchestration logic can materially change AI behaviour. They should be treated as security-sensitive configuration with access control, provenance, versioning, review and rollback.
External content should be considered untrusted input. Retrieval pipelines and tool interfaces require controls against prompt injection, malicious documents, poisoned knowledge sources and unauthorized instructions that attempt to override system policy or exfiltrate data.
Data security must follow the full AI lifecycle
AI data risk extends beyond the prompt window. Inputs may be logged, retained, used for evaluation, sent to external providers, cached in retrieval systems or exposed through generated output. Organizations need explicit rules for what data can enter which model, where it may be processed and how it is retained.
Classification and loss-prevention controls should be connected to model access. Highly sensitive data may require local or tightly controlled deployment patterns, explicit contractual safeguards, additional logging or a prohibition on particular external services.
Model integrity and software supply chain converge
Models, adapters, system prompts, code libraries, container images and evaluation assets all form part of the AI software supply chain. Teams should know where model artifacts came from, who can modify them, which versions are deployed and how changes are approved.
Integrity controls may include signed artifacts, controlled registries, version pinning, secure build pipelines, dependency scanning, environment separation and reproducible deployment records. A model update should be treated as a material system change when behaviour or risk can change with it.
Tool use turns model risk into action risk
When a model can call tools, security must govern both the model and the action. Tool interfaces should expose the minimum required capability, validate parameters, enforce business rules, rate-limit risky operations and isolate high-consequence functions.
The application should not assume that a model-generated tool call is trustworthy because it came from an approved model. Policy enforcement must exist outside the model so that unexpected or manipulated outputs cannot directly bypass business controls.
Runtime assurance closes the loop
AI systems need telemetry that connects model activity to identity, data access, retrieval, tool calls, policy decisions, external actions and human approvals. Monitoring should support both real-time containment and later reconstruction.
Useful signals include unusual tool sequences, privilege escalation attempts, anomalous data retrieval, repeated policy denials, changes in model version, prompt or configuration changes, high-risk output patterns and deviations from expected transaction behaviour.
Incident response needs AI-specific playbooks
Traditional incident-response processes remain relevant, but responders may also need to disable an agent, isolate a model endpoint, invalidate tool credentials, freeze retrieval sources, revert prompts, preserve model-version evidence and reconstruct chains of machine-generated actions.
Tabletop exercises should include scenarios in which the AI system behaves incorrectly without an obvious infrastructure compromise. Safety and security teams need a shared process for determining whether the cause is malicious input, model behaviour, data quality, configuration, compromised credentials or a third-party dependency.
Canadian AI Cyber research view
AI security will increasingly become an identity and authorization discipline. As systems gain autonomy, the question shifts from “what can the model say?” toward “what is this machine identity allowed to know, call, change and approve?”
A durable architecture treats AI systems as controlled participants in the enterprise: identifiable, least-privileged, monitored, governed by external policy, constrained at trust boundaries and recoverable when behaviour or assumptions change.