A practical Protected B AI architecture checklist

The control profile everyone still cites for Protected B predates the transformer. The Canadian Centre for Cyber Security profile for Protected B at medium integrity and medium availability carries a January 2015 document date and a 1 November 2012 page modification date. The two dates are incoherent on their face. We reproduce them as the publisher states them. The profile calls its controls “a starting point.” They “need to be tailored” to the context of each department. The cloud profile derived from it has since had its control list replaced by the Cyber Centre’s medium cloud control profile. It is a careful, still useful document. It has nothing to say about prompt injection or model provenance. It says nothing about retrieval grounding or an agent calling a tool. None of those existed as operational concerns when it was written.

Meanwhile the artificial intelligence specific guidance is months old, and nothing yet requires an authorization package to reflect it. An architect can satisfy every control in the older profile and ship a system with an unmitigated prompt injection surface. That gap is the real work.

Public Services and Procurement Canada (PSPC) publishes the definition, on a page last modified 27 August 2026. Protected B applies to information or assets that, if compromised, “could cause serious injury.” Protected A is injury; Protected C is injury at the gravest level.

The Cyber Centre’s Cloud Security Assessment Program page, last modified 19 June 2026, then splits Protected B in two, and this is the split that is easiest to get wrong:

Cloud Medium covers services processing up to Protected B “where there is a medium level of injury in situations of compromise to the availability and integrity of the system.”

Cloud High covers services processing up to Protected B “where there is a high level of injury” to availability and integrity.

Both top out at Protected B on confidentiality. They differ on integrity and availability. An artificial intelligence workflow that is Protected B but also load bearing for a service the public depends on may need Cloud High. A team can discover this only after it has architected for Medium.

Part of the Cyber Centre’s process is comparing attestations a provider already holds against the Canadian control requirements, rather than assessing every provider from scratch. The Cyber Centre published its cloud service provider assessment process document in October 2018, and it has been in effect since 1 October of that year. It states that at this time the Cyber Centre has compared only four attestation standards with the control and enhancement requirements of its lifecycle risk management catalogue:

• System Security Plans produced for the Federal Risk and Authorization Management Program (FedRAMP)
• American Institute of Certified Public Accountants (AICPA) System and Organization Controls (SOC) 2 Type II reports
• International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 27001 reports
• ISO/IEC 27017 reports

The same document says additional standards will be compared as the program matures, so treat this as the current list rather than a closed one. Name the four in your requirement anyway, because “appropriate certifications” is not a requirement.

Third party assessment organizations are, per the program page, “currently limited to companies with Federal Risk and Authorization Management Program (FedRAMP) accreditation”.

The Government of Canada Cloud Guardrails are a minimum set of security controls, mandatory since May 2022 under a standard attached to the Directive on Service and Digital. Departments “must implement, validate and report on compliance with the guardrails in the first 30 business days of getting access to their cloud account.” There are thirteen.

Four of them are where artificial intelligence workflows are most likely to break.

Data location. Where the prompt goes, not only where the corpus sits. A retrieval pipeline that keeps documents in Canada and sends the retrieved passages across a border has moved the data.

Protection of data at rest. Vector stores and embedding indexes are derived copies of the source material. Teams can create them outside the controls that apply to the source.

Protection of data in transit. Every tool call is a transit event, and agent architectures multiply them.

Logging and monitoring. If the logs do not record which documents the system retrieved and which tools it called, nobody can reconstruct an incident involving the system.

A fifth, configuration of cloud marketplaces, deserves a mention because it is where model and artificial intelligence service subscriptions quietly get procured outside the process everyone believes they are inside.

The Cyber Centre published its primer on the top ten artificial intelligence security actions in May 2026, last modified 29 May 2026. It is recent enough to carry the structure of any Protected B design review, and it should. The ten actions start with mitigating prompt injection and jailbreaks. They go on to defending against deepfakes and impersonation, and hardening against artificial intelligence powered attacks and fraud. The primer then asks for testing and red teaming, and for safeguards against data poisoning. It also covers data usage controls and model theft prevention. It adds secure engineering and supply chain, and the enforcement of privacy, vendor and contractual controls. It ends with human in the loop oversight and execution controls, and with operational resilience against drift and hallucination as well as bias and overreliance.

Six of those, in our reading, map onto controls a mature security program already runs. Four are new work:

A bill of materials for the system itself. The primer asks for an artificial intelligence bill of materials covering its models and datasets and their dependencies, with models, code and artifacts cryptographically signed or hash validated. It is the newest of the items here and the one least likely to be already in place.

No train defaults, enforced. Not asserted in a vendor’s marketing page. Enforced in configuration and written into the contract, alongside audit rights and use restrictions.

Prompt level data minimization. The primer asks institutions to “classify and minimize personally identifiable information (PII) in prompts.” The prompt is a new data path that existing classification schemes were not written for, and it is the one users interact with directly.

Shadow artificial intelligence discovery. Mapping sanctioned and unsanctioned models on the network, with allow and deny lists. Expect the discovery exercise to find more models in use than your inventory records.

For model hosting and supply chain specifically, the Cyber Centre published guidance on securely deploying artificial intelligence at the network edge on 14 July 2026. It covers model integrity protection, cryptographic binding, secure disposal, and both software and model bills of materials. It is two months old and is the most current thing available.

One honest gap: neither that document nor the Cyber Centre’s generative artificial intelligence guidance addresses retrieval augmented generation. Retrieval is the usual pattern for a knowledge workflow, and it is the pattern least covered by current guidance. Architects should document their retrieval design decisions on the assumption that the guidance will arrive later and will be applied retroactively.

Canada’s federal privacy authorities and their provincial and territorial counterparts, including the Office of the Privacy Commissioner of Canada, published principles on 7 December 2023. The principles cover generative artificial intelligence technologies that are responsible and trustworthy and that protect privacy. They were last modified on 6 May 2025. Nine principles: legal authority and consent; appropriate purposes; necessity and proportionality; openness; accountability; individual access; limiting collection, use and disclosure; accuracy; safeguards.

Individual access is the requirement most easily missed at design time. A person may ask what personal information about them the institution holds. If their information was embedded into a vector index, that index is now in scope for the answer, and retrieving it requires a capability nobody built.

The Privacy Act governs how federal institutions handle personal information. The Personal Information Protection and Electronic Documents Act governs commercial activity in the private sector. Both apply on their own terms, independently of anything in this checklist.

Category and injury level, with integrity and availability assessed separately from confidentiality. Provider attestations, the four named ones. The thirteen guardrails, with data location, data at rest, data in transit and logging examined specifically against the retrieval and tool call paths. The ten security actions, with the four new ones resourced rather than acknowledged. The nine privacy principles, with individual access designed for rather than discovered.

None of that is exotic. All of it is cheaper before the build than after, and the profile you are being assessed against will not tell you any of it.

Previously: five knowledge workflows Canadian public institutions can pilot safely. Next in this series: bilingual evaluation for Canadian government AI workflows.