A traveler with no documents
A human employee who crosses into a new department needs a new badge, new login, and usually someone's sign-off. An AI agent that expands from summarizing claims files into touching a payments system typically needs none of that. It just needs a developer who found a working API call and no one in the loop asking whether it should.
That asymmetry is the actual subject here, and it's worth naming precisely: organizations issue identity and travel documents to people crossing borders, but let AI agents cross system boundaries — customer data to payment rails, read access to write access, one department's records to another's — with nothing that functions as a passport. No record of where the agent has been, what it's authorized to do at each stop, or who vouches for it. When something goes wrong, there's often no clean way to answer the first question an investigator asks: what could this thing actually do, and how did it get permission to do it?
Canada's federal government has, for its own systems, already answered part of this question. The Treasury Board's Directive on Automated Decision-Making requires federal institutions to conduct algorithmic impact assessments before deploying automated systems that affect decisions about people. That's a form of pre-departure screening — an assessment of risk before the system is allowed to operate. It exists because someone in government recognized that automated systems making consequential decisions need a documented basis for doing so, reviewed before deployment rather than discovered after an incident.
The private sector has no equivalent obligation. A Canadian bank, insurer, or retailer deploying an AI agent internally faces no legal requirement to conduct anything like an impact assessment first. The passport metaphor holds uncomfortably well: government employees need documented authorization to do their jobs across borders; government AI systems, in principle, need documented authorization too. Private-sector AI agents, doing materially similar work with materially similar access, mostly don't.
What a passport would actually contain
Push the metaphor past its poetic use and it becomes a specification. A passport works because it answers four questions on demand: who is this, who issued the credential, what are they authorized to do, and can that authorization be revoked. Applied to an AI agent, those questions translate into identity, provenance, scope, and revocability — and Canadian organizations building agent governance are, whether they use this language or not, building answers to exactly these four questions.
Identity means the agent is a distinct, tracked entity — not a shared service account, not an anonymous process inheriting whatever permissions the last integration left behind. Provenance means there's a record of who deployed it, what model or vendor stack underlies it, and when its permissions last changed — the equivalent of knowing which authority issued the document and when it was last renewed. Scope means documented boundaries: this agent can read this database, cannot write to that one, cannot reach payment systems at all, regardless of what a later integration makes technically possible. Revocability means someone can pull the agent's access immediately, without a deployment freeze or a scramble through unfamiliar infrastructure, and that pulling it doesn't quietly break three other workflows nobody mapped.
The frameworks converge on roughly this shape. NIST's AI Risk Management Framework treats governance as a lifecycle discipline — map, measure, manage — rather than a one-time approval. ISO/IEC 42001 formalizes AI management systems the way ISO 27001 formalized information security management: as an auditable, continuously operated program, not a document produced once for a compliance file. None of these frameworks were written with a passport analogy in mind. But strip away the acronyms and each is answering the same underlying question a passport answers: on what basis, and under whose authority, is this entity allowed to act?
Where the analogy breaks — and why that matters more
Here's the honest limitation, and it's worth stating plainly rather than papering over it: a passport is a static document. It's issued once, checked at intervals, and revoked through a formal process that assumes the holder's identity and rights don't shift on their own between checks. An AI agent's scope is not static. It can be reconfigured by a single API change, a new integration, or a permissions update pushed by a vendor — all without triggering anything resembling a border check.
That's not a minor wrinkle in the metaphor. It's the reason passport-style governance, applied to AI agents without adaptation, would fail. A document checked once at deployment and then trusted indefinitely tells you nothing about what the agent can do six months later, after three "reasonable" scope expansions each approved locally by a team trying to ship a feature. The Canadian financial services scenario that keeps surfacing in governance discussions — an agent scoped for account inquiries and low-value transfers that quietly grows into adjacent systems — isn't a failure of having no passport. It's a failure of nobody re-checking the passport at each new border it crossed.
The practical implication is that agent governance needs something a paper passport doesn't: continuous re-verification, not point-in-time approval. That means access reviews triggered by scope changes, not calendar dates. It means an owner who is notified automatically when an agent's permissions change, not one who discovers the change during an annual audit. It means the underlying access architecture is built so that expansion requires a new authorization event, rather than happening silently because the technical door was already unlocked.
The counterargument worth taking seriously
The strongest objection to all of this isn't that governance is unnecessary — it's that Canada doesn't yet have a legal instrument that requires it outside government, and building an internal passport system ahead of any mandate is a real cost with no regulatory deadline forcing the issue. The Artificial Intelligence and Data Act, tabled in 2022 as part of Bill C-27, was meant to become that instrument for the private sector. It has not become binding law. Organizations that wait for it are not breaking any current rule.
That argument has force, and it deserves a direct answer rather than dismissal. The answer is that AIDA, if and when it takes effect, will set a floor — a minimum standard checked after deployment, for systems already in production making decisions that already happened. An organization with no internal identity and scope discipline for its AI agents isn't in a defensible position while it waits; it's in a position where its first serious incident, not a future law, will be the audit. The federal government's own directive shows what the eventual private-sector expectation is likely to resemble: documented, pre-deployment assessment of what an automated system is authorized to do, not a retrospective explanation produced after something goes wrong.
The choice this actually forces
Every organization deploying AI agents is making a decision right now, whether or not it's being made deliberately: either someone owns the question of what each agent is authorized to do and can prove it on demand, or no one does, and the organization will find out which is true during its first serious incident rather than before one.
A passport doesn't stop a traveler from misbehaving once they've crossed the border. It does mean that when they do, there's a record of who let them in, on what authority, and what they were supposed to be doing. For most Canadian organizations running AI agents today, that record doesn't exist yet. The uncomfortable question isn't whether to build it. It's whether the first time anyone tries to produce it will be by choice, or under investigation.
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.