The Booking That Exposes the Problem
A Canadian traveller asks an AI agent to book a hotel in Montreal, stay under $400, and confirm by end of day. Nothing about that request looks dangerous. But fulfilling it means the agent has to cross into systems belonging to a search provider, a travel intermediary, a hotel, a payment network, and the traveller's own bank — often without a human checking each handoff. Every one of those parties has to answer the same question before it lets the transaction through: who does this agent represent, what is it actually authorized to do, and does this specific action fit inside that authority?
That question is not new. It's the same question every access-control system has always asked. What's new is that the party asking to act is software making its own sequence of decisions, not a person clicking through a checkout flow. The infrastructure built to answer that question — identity providers, OAuth scopes, payment rails, audit logs — was built assuming a human sits behind the request. Agentic AI breaks that assumption in a specific, traceable way, and the industry's own standards bodies are now saying so directly.
What NIST Is Actually Building
In February 2026, NIST announced its AI Agent Standards Initiative, describing its purpose as ensuring that "AI agents capable of autonomous actions" can be "widely adopted with confidence" and "function securely on behalf of their users" while interoperating "smoothly across the digital ecosystem." That framing matters more than it first appears. NIST is not proposing a parallel security discipline for AI. It's saying explicitly that agentic AI needs disciplined extension of the controls that already exist — zero trust architecture, identity and access management, OAuth, PKI, payment authorization, logging — applied to a category of identity those controls were never built to hold: software that acts.
The initiative is organized around three pillars, according to analysis from the Cloud Security Alliance: catalyzing industry-led technical standards, fostering open-source protocol development, and advancing research specifically into AI agent security and identity. NIST's own announcement frames the goal partly in competitive terms — cementing U.S. leadership in the standards that will govern this ecosystem — which is worth noting for Canadian organizations that will be adopting rules written elsewhere, not writing them.
The gap NIST is responding to is concrete. Its existing Cybersecurity Framework 2.0 and AI Risk Management Framework provide a structured way to think about AI risk in general terms, and CISA's own AI RMF guidance already calls for unique identities, least-privilege access, and human approval for high-impact actions. But neither framework, nor the broader control catalog in SP 800-53, contains specific provisions for short-lived, scoped, machine-enforceable credentials, or for evaluating risk at the moment an agent decides to act rather than at the moment a human logs in. That's the reason NIST opened a formal Request for Information on updates to SP 800-160 and SP 800-218 aimed squarely at agentic attack surfaces. The standards body responsible for a huge share of the infrastructure Canadian organizations already rely on is telling the market, in writing, that the current control set doesn't cover this case.
Where the Convergence Stops Short
Several strands of existing security work are converging toward the same shape of answer, even though none of them were designed with agents specifically in mind. FIDO passkeys and WebAuthn establish strong, phishing-resistant identity. OAuth 2.1 and verifiable credentials support scoped, revocable authorization. Payment networks already enforce hard transaction limits at the infrastructure level, independent of what an application claims it's allowed to do. Put together, these pieces suggest a workable direction: agents get their own identities, their own scoped and short-lived credentials, and their actions get evaluated against risk in real time rather than trusted by default.
Where that convergence stops is the part that should concern anyone deploying agents against real systems today: the technical separation between untrusted content and trusted instructions is still incomplete. An agent that reads a webpage, an email, or a document as part of its task can have its next action shaped by text embedded in that content — a prompt injection — and current architectures do not reliably distinguish "information the agent is reading" from "instructions the agent should follow." This is not a hypothetical edge case; it's recognized by CISA and other standards bodies as a first-class attack surface in agentic systems specifically because the boundary between data and instruction hasn't been solved, only mitigated. A trust model built entirely around identity and authorization can still fail here, because the agent may be correctly identified, properly authorized, and still act on a manipulated instruction it received mid-task from content it was never supposed to treat as a command.
That's the honest limitation of everything else in this article. Identity and authorization answer "is this agent allowed to act at all." They do not fully answer "was this specific action the agent's own legitimate decision or an instruction smuggled in from something it read."
A Structure Worth Adopting
Given that gap, the useful move is not to invent new security primitives but to sequence the ones that already exist so each stage constrains the next. A defensible structure looks like this: Identify the agent with a unique, non-human credential distinct from any human user it acts for. Authorize it against a specific, narrow scope rather than a broad role. Constrain that authorization with short-lived, revocable credentials so a compromised session expires quickly. Execute only after a runtime risk check evaluates the specific action against the specific context, not just the agent's general permissions. Verify the outcome against the original intent before treating the action as final. Record every step in a log detailed enough to reconstruct the decision afterward. Revoke access immediately when something looks wrong, without waiting for a scheduled review. Recover through a fallback process that was tested before it was needed, not improvised after an incident.
This is a generalization of a simpler chain — human intent, agent action, an authority that grants permission, the action itself, and the evidence trail left behind — stretched into enough discrete steps that each one can fail without the whole chain failing silently. The value of the extra steps is specifically that verification and recording happen after execution, not just before it, which is where prompt-injection-driven actions are most likely to surface: not in whether the agent was authorized, but in whether what it actually did matches what it was supposed to do.
What This Costs, and Who Owns It
None of this is free. Every added step — a runtime risk check, a post-execution verification, a detailed log — is friction against a technology being sold on speed and reduced headcount. An organization that builds this sequence properly will move slower than one that wires an agent directly into a payments API and calls it done. That tradeoff won't resolve itself; it has to be decided deliberately, system by system, by someone with the authority to say no to a faster rollout.
For Canadian organizations specifically, there's a second decision hiding underneath the technical one. The standards converging on this model — NIST's initiative chief among them — are being written largely outside Canada, with an explicit stated interest in shaping global adoption on terms favourable to the jurisdiction writing them. Canadian financial institutions, insurers, and public-sector bodies deploying agentic AI now will be adopting a rulebook authored elsewhere, and CCCS and OSFI guidance will need to catch up to something that's already shipping. Waiting for that domestic guidance to mature before building the identify-authorize-constrain sequence isn't caution. It's deploying agents today under yesterday's access model and hoping the gap between the two doesn't get found first by an attacker instead of an auditor.
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.