The question nobody assigned
Ask a Canadian security leader who owns the firewall and they'll name a team. Ask who owns the identity provider and they'll name a team. Ask who watches what an AI agent actually does once it's live in production, and the honest answer, most of the time, is nobody in particular. Not because the question is unimportant, but because nobody wrote the job description.
That gap is the real subject of AI agent governance, and it's worth being precise about why it opened up. Traditional access control was built for people and for static software: a person logs in, a role determines what they can touch, and that mapping stays roughly stable until someone in IT changes it. An AI agent breaks that model in two ways. It acts continuously rather than in discrete logged-in sessions, and its useful scope tends to grow — not through a breach, but through the ordinary mechanics of a successful pilot. Vendor research on agent permissioning, including work from identity platform Auth0, makes the underlying point directly: traditional access control models were not designed for autonomous systems that plan and execute multi-step actions on their own, and applying them as-is leaves a structural gap between what an agent was scoped to do and what it can actually reach.
How the gap actually opens
The pattern is mundane, which is exactly why it's dangerous. A firm gives an agent narrow, sensible access to solve one problem. The agent works. Someone connects it to an adjacent system to solve the next problem, because that's faster than filing a change request. Six months later the agent's effective permissions look nothing like what was approved at launch, and there is no single document anyone can point to that describes its current footprint.
Cerbos, a vendor building access-control infrastructure specifically for AI systems, frames this as a permissions problem rather than a behavior problem: agents without properly scoped access controls can reach sensitive data and hand it to people who were never meant to see it, not because the agent is malicious, but because nothing was defining the boundary in the first place. The New Stack's reporting on agent permission design adds a sharper operational detail worth sitting with: the policy layer governing what an agent can do has to rely on metadata controlled by engineering — hard boundaries — not on trust settings that a project team can quietly loosen because a deadline is close. Trust settings bend under pressure. Metadata boundaries, enforced in code, don't bend without someone deliberately changing them and leaving a record.
That distinction matters more than it sounds. A trust setting is a policy decision that lives in someone's head or in a configuration screen a project manager can edit. An engineering-enforced boundary is a decision that survives the people who made it. Canadian organizations building or buying agentic AI right now are, whether they've named it or not, choosing between those two models every time they approve an integration.
Who actually has to answer the question
This is where governance frameworks stop being abstract and start assigning names. Airia's framework for AI agent governance breaks the problem into layers that map cleanly onto real accountability: identity — establishing which agent this is and under what authority it's acting; authorization — what that identity is currently permitted to do; and guardrails and constraints — the behavioral boundaries layered on top of authorization to catch what permission alone won't. The value of separating these layers isn't academic. It means that when something goes wrong, there's a specific layer to interrogate rather than a general shrug. Was this an identity failure — the wrong agent had credentials it shouldn't have had? An authorization failure — the right agent had permissions nobody approved? Or a guardrail failure — permission was correct but behavior wasn't?
Most organizations deploying agents today can't answer that question cleanly, because they never built the layers separately. Identity, authorization, and behavior get bundled into one loose approval at launch and never revisited. Auth0's guidance pushes toward the same separation from a different angle: it recommends scoping agent permissions to specific execution plans and tying them to short-lived, revocable credentials rather than standing access — the AI equivalent of a temporary building pass that expires instead of a master key that doesn't. Short-lived credentials don't prevent an agent from misusing access during the window it has it. What they do is limit how long a mistake or a compromise stays open, and they force a renewal decision at intervals instead of letting access accumulate silently.
The human-in-the-loop question, answered honestly
The obvious counterargument to all of this is that human approval gates solve the problem outright: put a person in the loop before anything consequential happens, and the agent can't do damage without someone signing off. This is true, and it's also incomplete in a way that matters for how Canadian leaders should actually design these systems.
Research on human-in-the-loop design from CreateOS makes a useful distinction: approval gates belong at the specific points where the cost of a mistake exceeds the cost of the delay a human review introduces — not everywhere, and not nowhere. That sounds like a compromise, but it's actually a discipline. Gate every action and the agent becomes a slower, more expensive version of a human process, which defeats the reason for deploying it. Gate nothing and you've built exactly the risk this article is describing. The judgment call — which actions cross the threshold where delay is worth it — is a business decision dressed up as a technical one, and it's usually being made by whoever configured the pilot, under time pressure, without a mandate to weigh it carefully.
The New Stack's reporting reinforces where that threshold should sit at minimum: any action that sends a message externally, on the organization's behalf, to someone outside it, should require a named person's sign-off — not a policy default, not a role, a specific accountable individual. That's a narrow, testable rule, and it's a useful anchor precisely because it doesn't try to cover every case. It covers the case where the downside is public and hard to walk back.
The tradeoff nobody wants to say out loud
Here is the uncomfortable part. Every mechanism described above — scoped identity, short-lived credentials, separated authorization layers, engineering-enforced metadata boundaries, human approval gates at defined thresholds — adds friction, cost, and slower iteration to a technology whose entire commercial pitch is speed and reduced headcount. An organization that builds all of this well will deploy agents more slowly than a competitor that doesn't. That's not a hypothetical tension; it's the actual tradeoff every governance framework in this space is asking leaders to accept, and none of the vendor material reviewed here pretends otherwise.
The honest answer to "who watches the agents" is not a tool or a checklist. It's a named person or team whose job explicitly includes knowing the current, actual scope of every agent in production — not the scope it launched with — and who has the authority to revoke access without needing three approvals to do it. If that person doesn't exist in your organization today, the agents you already have deployed are being watched by nobody, running on whatever access they accumulated on the way to working well. That's not a future risk. It's the current state in a large share of the organizations that have moved past the pilot stage, and it will stay that way until someone is made accountable for the answer, not the deployment.