When the compromised thing was trusted, the logs look clean

Six national cyber agencies put their names to the same document this spring. Canada’s Centre for Cyber Security was one of them. It contains a recommendation I do not think financial services has reckoned with.

The guidance is that organisations should use agentic AI only for low-risk, non-sensitive tasks, and should not grant agents broad or unrestricted access.

Now look at where the investment is actually going. Lending decisions. Collections. Procurement approvals. Payments. Not one of those is low-risk. Not one is non-sensitive.

I am not arguing that the agencies are right and the roadmaps are wrong. I am pointing out that nobody has had that argument out loud, and it will be had eventually — in a room, under pressure, with a date attached. Better to have it now, on your own terms.

The worked example every technology committee should read

The document walks through a scenario. An agent is given broad access to financial systems, email and contract repositories to reduce friction. Its permissions are evaluated once, at deployment. Someone compromises a minor tool in its workflow and inherits everything the agent could do.

Here is the part an architect notices and a policy summary leaves out. The actions that follow produce audit logs that look legitimate. The evidence trail is clean precisely because the thing doing the damage was trusted.

Your detection model assumes a bad actor looks different from a good one. A hijacked agent with standing permissions does not.

Governance built for people does not transfer

The agencies also say something quieter and more useful: governance designed for human actors does not carry over to autonomous agents. That is not a warning about AI. It is a warning about reusing your existing approval process.

Most institutions govern agents the way they govern service accounts — long-lived credentials, broad scope, approved once. That model was tolerable when the account ran one predictable job. It is not tolerable when the account chains tools across systems on someone’s behalf and decides for itself which tool to call next.

What closes the gap is not a new policy. It is four architectural properties: an identity per agent rather than a borrowed one; authority scoped to the task and the time window, not to the project; policy evaluated at the moment of each action rather than once at deployment; and an audit trail that ties every action back to the person or process that delegated it. With those in place, a hijacked agent starts to look different from a healthy one — because it tries to do things its scope never allowed.