By Maple & North
The permission you already gave away
Somewhere in your organization right now, an AI agent has access it was never formally granted. Not through a breach — through a pilot project that worked. A team member connected an agent to a shared inbox, a CRM, or a document repository to solve a real problem, the demo impressed the right people, and six months later the agent is touching production systems with nobody able to say precisely who approved that, what it's allowed to do, or how to shut it off cleanly if it starts doing the wrong thing well.
This is not a hypothetical failure mode. It is the default path for agentic AI adoption in Canadian workplaces, and it's why the Canadian Centre for Cyber Security published guidance treating AI systems as security infrastructure rather than productivity tools. The Cyber Centre's top-10 primer on AI security actions exists because the gap between "we deployed an agent" and "we govern an agent" is where incidents happen. The federal government's own Guide on the Use of Agentic Artificial Intelligence draws the same line, distinguishing agentic AI — systems that sequence steps, interact with other systems, and pursue goals within set boundaries — from generative AI that simply answers prompts. That distinction matters because the checklist for a chatbot and the checklist for something that can move money, change records, or lock accounts are not the same document.
This article is that second checklist, built for the Canadian workplace where an agent already has, or is about to get, real operational authority.
What "governed identity" actually requires
The core idea running through federal guidance is that an AI agent should be treated as a governed identity, not an informal tool. That phrase sounds abstract until you translate it into what it forbids: an agent should not have access nobody assigned, actions nobody can trace, or authority nobody can revoke on short notice. Every one of those three failure states is common in early agent deployments, precisely because agents get bolted onto existing systems using whatever credentials were convenient at the time.
Recent joint guidance aimed at businesses experimenting with agentic AI in customer support, procurement, IT operations, or finance makes the risk explicit: agentic AI inherits every weakness of the underlying language model, then adds a wider attack surface, more autonomy, and harder-to-trace accountability. The guidance's recommendation is blunt — never grant agentic AI broad or unrestricted access, and limit it to low-risk, non-sensitive tasks until oversight and evaluation methods mature. That is a meaningfully more conservative position than most vendor sales material, and it should be read as a signal about where the authoring agencies think the real exposure sits: not in the model's intelligence, but in the scope of what it's permitted to touch.
For a Canadian business, this has a practical implication. If your agent can access customer financial data, initiate transfers, or modify records, the appropriate question isn't "is the model good enough?" It's "would we let a new, junior employee with unverified judgment have this exact level of access, unsupervised, on their first week?" If the answer is no, the agent shouldn't have it either — no matter how well it performed in testing.
Where the checklist earns its keep
A checklist is only useful if it forces a decision at each step, rather than becoming a box-ticking exercise. Five items, applied honestly, cover most of what goes wrong.
Inventory every AI dependency before you inventory anything else. Most organizations cannot currently produce a complete list of which workflows depend on an AI agent, which vendor or model sits behind it, and what breaks if that dependency disappears. Build that list first. You cannot govern what you haven't mapped.
Assign an accountable owner, by name, for every agent or AI-enabled workflow. Not a team. Not "IT." A person who can answer, in an incident review, exactly what the agent was authorized to do and why. If no one can be named, the agent should not be in production. This is the same logic Canada's Algorithmic Impact Assessment tool applies to automated decision systems in government: the mandatory questionnaire forces departments to score impact levels before deployment, precisely because an unscored, unowned system is an ungoverned one.
Document access controls, authentication, logging, approval boundaries, and revocation paths — and treat the documentation as a living artifact, not a launch requirement. Agents get expanded permissions over time as teams find new uses for them. If the documentation isn't updated alongside the access, you have drift, and drift is where governance quietly fails months after everyone stopped paying attention.
Test fallback options and incident response playbooks before you need them. An agent that can freeze an account, deprioritize a case, or approve a transaction is a single point of failure if there's no tested manual path around it. The test itself matters more than the plan on paper — a playbook nobody has rehearsed is a hope, not a control.
Build AI availability, jurisdictional risk, and auditability into procurement, not into the incident response after something goes wrong. Ask vendors directly where data is processed, who can access logs, and what happens contractually if the model or platform becomes unavailable. If a vendor can't answer clearly, that's the answer.
The counterargument worth taking seriously
The strongest pushback against this checklist approach is that it slows adoption in a country trying to catch up. Canada's national AI strategy explicitly frames AI adoption as a competitiveness priority — building sovereign infrastructure, scaling Canadian AI companies, and helping more businesses adopt AI faster. A rigid governance checklist applied to every pilot project risks becoming the reason a small business never gets past its first agent deployment while competitors elsewhere move faster with looser rules.
That's a fair tension, not a strawman. The honest answer is that governance intensity should scale with authority granted, not apply uniformly. A customer-facing chatbot answering FAQ questions does not need the same control stack as an agent with write access to a core banking system. The mistake is not having a checklist — it's applying the same checklist weight to every deployment regardless of what the agent can actually do. Canadian organizations that get this right will triage fast: low-risk, non-sensitive tasks move quickly with light oversight; anything touching money, personal data, or irreversible actions gets the full governance treatment before go-live, not after.
The choice that doesn't go away
The uncomfortable part of this checklist is that it doesn't resolve the underlying tension — it just makes the tradeoff visible. Every item on this list adds friction: an owner who has to say yes, documentation that has to be maintained, a fallback path that has to be tested and therefore costs money even when it's never used. Organizations that skip the checklist move faster right up until an agent does something nobody authorized, at which point the absence of an accountable owner, a tested fallback, or an auditable log becomes the story — not the AI failure itself.
Canadian organizations deploying agents this year are making that tradeoff whether they name it or not. The ones that name it, and decide deliberately how much friction each workflow deserves, are the ones that will still be able to answer the only question that matters after an incident: who knew this agent could do that, and why did we let it?