Scope creep has a new name, and it moves faster than the committee that approved it
Every organization that has deployed an AI agent has a version of this story. The agent was approved to do one thing — summarize account inquiries, triage support tickets, flag suspicious transactions for human review. The scope was written down, the pilot was scoped tight, and somebody signed off on exactly what it could touch.
Then it worked. And because it worked, someone asked a reasonable question: since the agent can already read the claims database, why not let it also check the payments system before escalating a case? Since it can already summarize a file, why not let it draft the response too? Each expansion solved a real problem. None of them went back through the approval that governed the original deployment, because none of them felt like a new deployment. They felt like a feature.
Six months later, nobody can produce a current, accurate list of what the agent actually has access to — only what it was scoped to access when the project started. That gap between documented scope and actual scope is not a hypothetical risk. It is the default trajectory of unmanaged AI deployment, and it is the direct subject of the Canadian Centre for Cyber Security's guidance on AI security, which identifies scope expansion without oversight as a recurring pattern behind data exposure, unauthorized access, and operational loss tied to AI systems.
Why "it still does its job" is the wrong test
The instinct inside most organizations is to judge an AI agent by whether it's still doing its job well. That's the wrong test, and it's worth being precise about why.
An agent that has quietly accumulated access beyond its original mandate can be performing its assigned task perfectly while also representing a materially larger risk than the one that was approved. The Cyber Centre's framing is useful here: AI systems carry novel security vulnerabilities that sit alongside standard cyber threats, not instead of them. A payments-adjacent agent with claims-database access isn't just a claims tool anymore — it's a new attack surface, a new compliance question, and a new single point of failure, even if every output it produces still looks correct.
This is where the Cyber Centre's broader guidance on secure AI system development becomes relevant beyond the deployment stage. Its core observation — that when the pace of AI development is high, security tends to become a secondary consideration — describes exactly the mechanism by which scope creep happens. Nobody decides, in a meeting, to weaken the agent's boundaries. The boundaries just stop being anyone's job to defend once the original approval has been granted and attention has moved on to the next priority.
The Canadian regulatory floor is lower than most leaders assume
Executives often assume that if an AI deployment were truly risky, some regulation would already require them to control it. In Canada, that assumption doesn't hold yet. There is no general federal law governing AI systems currently in force. The Artificial Intelligence and Data Act, tabled as part of Bill C-27, was intended to fill that gap, but it remains unfinished business rather than enforceable law — and Canadian organizations deploying agents today cannot rely on it to define their obligations.
What exists instead is a patchwork, and a thinner one than many organizations realize. Ontario has passed a law requiring employers to disclose AI use in hiring — a narrow, sector-specific rule, not a general AI governance standard. Federal and provincial privacy regulators have issued joint guidance on applying existing privacy law to generative AI, which is useful but addresses privacy exposure specifically, not the broader question of what an agent is allowed to touch and who is accountable when it touches more than that. A voluntary code of practice for generative AI systems exists to let companies demonstrate responsible development ahead of formal regulation, but voluntary is the operative word.
The practical conclusion for Canadian leaders is uncomfortable but clear: waiting for AIDA, or treating current privacy guidance as sufficient AI governance, is waiting for a floor that isn't finished being poured. The Cyber Centre's operational guidance — its top AI security actions, its secure development guidelines — is the most concrete, enforceable-in-practice standard available to Canadian organizations right now, precisely because it doesn't wait on legislation to tell organizations what responsible scope management looks like.
The honest counterargument: controls cost you speed
It would be dishonest to present strict access governance as a free improvement. It isn't. Every one of the Cyber Centre's recommended controls — documented access boundaries, a named accountable owner, logging sufficient to reconstruct what an agent did and why, a defined approval process before scope changes, tested revocation paths — adds friction to exactly the kind of iteration that makes AI agents commercially attractive in the first place.
The team that wants to let the claims agent check payments data before escalating a case is not wrong that doing so would help. They're responding to a genuine gap. The discipline of routing that expansion through a formal review, rather than shipping it as a quiet feature update, is slower. An organization that insists on that discipline will, in the near term, deploy fewer agent capabilities than a competitor willing to skip the paperwork. That tradeoff is real, and any governance framework that pretends otherwise is not being honest with the leaders it's advising.
The defensible position is not that controls are costless. It's that the cost of controls is visible and bounded — a delayed feature, a review meeting, an owner who has to sign off — while the cost of their absence is invisible until it isn't: an agent with access nobody fully mapped, operating in a system nobody is specifically watching, until an incident forces the mapping to happen under worse conditions.
What accountable scope management actually requires
Treating an agent's scope as a governed boundary rather than a starting point that naturally expands means a few concrete things have to exist before the next "why not just let it also..." conversation happens:
A current inventory of what each agent actually accesses — not what it was approved to access at launch, refreshed on a schedule, not assumed accurate because nobody has complained. A named owner for each agent who is accountable for approving scope changes, not just for the agent's original deployment. Logging detailed enough that if an agent did something unexpected, someone could reconstruct exactly what it touched and why, after the fact, without guessing. A defined threshold — in dollar value, data sensitivity, or system criticality — above which a scope change requires the same approval rigor as the original deployment, not a quiet pull request. And a revocation path that has actually been tested, not just documented, so that removing access doesn't become its own multi-week project when it's urgently needed.
None of this is exotic. It's the same discipline organizations already apply to human employees changing roles — new access, new sign-off, a record of who approved it. The gap is that AI agents cross those same boundaries constantly, incrementally, and usually without anyone treating the crossing as the kind of event that warrants a fresh look.
The choice underneath the governance framework
The real decision facing Canadian organizations isn't whether to adopt a governance checklist — most of the controls above are already written down in Cyber Centre guidance, free to read, uncontroversial in substance. The real decision is whether an organization is willing to slow down a working, popular deployment to re-approve what it has already quietly become.
That's a harder call than it sounds, because the agent that exceeded its scope is usually also the agent that's delivering value. Pulling it back for review looks, from the outside, like punishing success. The organizations that get this right will be the ones willing to make that call anyway — not after an incident forces it, but as a routine cost of running AI agents at all.
What Leaders Should Do Security and technology leaders should treat AI systems and autonomous agents as governed identities, not informal tools. In practical terms, they should:
- Inventory critical ai dependencies.
- Assign an accountable owner for each agent or ai-enabled workflow.
- Document access controls, authentication, logging, approval boundaries, and revocation paths.
- Test fallback options and incident response playbooks.
- Include ai availability, jurisdictional risk, and auditability in procurement.