by Maple & North
A mid-sized Canadian financial services firm rolled out an AI agent to handle routine account inquiries and initiate low-value transfers on customer request. The rollout followed a familiar pattern: a successful pilot, growing confidence, and an expanding list of systems the agent could access. Six months later, someone in IT security asked the question that should have come first:
When this agent logs into the core banking system, whose identity does it use?
At most organizations experimenting with agentic AI today, the honest answer is surprisingly simple: nobody really knows.
The agent may be running under a shared service account. It may still be using an API key created by a developer during the pilot. It may have inherited permissions from the first person who configured it, permissions that quietly expanded as the project grew and were never reviewed again.
This isn't an unusual mistake. It's what happens when organizations move faster than their governance.
Maple sees something interesting in that moment. Most employees don't worry about workload identities or OAuth scopes. They worry about something much simpler: if this AI agent makes a mistake, whose name ends up in the investigation?
That question sits at the centre of the next stage of enterprise AI.
For decades, identity has been one of cybersecurity's most mature disciplines. Organizations know how to create identities for employees, contractors, vendors, applications, and privileged administrators. They understand authentication, authorization, lifecycle management, and least privilege because they've spent years learning difficult lessons through breaches, audits, and regulatory scrutiny.
AI agents introduce an entirely different challenge.
Unlike traditional software, an AI agent doesn't simply execute a predefined workflow. It receives objectives, determines how to accomplish them, selects tools, accesses systems, and makes decisions within the boundaries it has been given. To do any of that, it needs an identity.
Not a username.
Not a friendly display name.
A real enterprise identity capable of authenticating, requesting access, calling APIs, opening databases, reading email, or interacting with business systems.
That identity quickly becomes one of the most powerful non-human identities inside an organization.
Current guidance from NIST describes agentic AI as software capable of pursuing high-level goals through planning, reasoning, tool use, and multi-step execution. Those capabilities make AI agents significantly different from scripts or robotic process automation. They are dynamic. They adapt. They choose among available tools. Every one of those actions depends upon identity.
Vendors understandably focus on what AI agents can accomplish. Identity professionals tend to ask a different question.
What should they be allowed to do?
That distinction matters.
An AI agent that can summarize documents may only require read-only access to a repository.
An AI agent responsible for resetting passwords requires much broader privileges.
An AI agent initiating financial transactions, approving workflows, or updating customer records enters an entirely different category of risk.
Identity determines those boundaries.
Security teams have spent years reducing standing privilege across human accounts. Just-in-time access, least privilege, privileged access management, Zero Trust, and continuous verification all emerged because organizations learned that excessive permissions eventually become security incidents.
The same lesson applies to AI agents.
Granting an agent broad, persistent credentials simply because it may need them one day repeats mistakes security teams have already spent years trying to eliminate.
Some organizations have suggested treating AI agents like service accounts.
Others propose workload identities or machine identities.
Each model solves part of the problem.
None solves accountability.
A distinct identity improves traceability.
It does not answer who owns the consequences of that identity's actions.
Maple would argue that identity has never really been about technology. Identity is simply how an organization answers one of cybersecurity's oldest questions:
Who did what?
With AI agents, that answer is becoming much harder to provide.
Consider an AI agent supporting customer service.
It reads emails.
Retrieves customer histories.
Updates records.
Creates support tickets.
Schedules appointments.
Generates responses.
Every one of those actions may touch a different business system, each governed by different security controls, compliance obligations, and audit requirements.
From the customer's perspective, it feels like a single conversation.
From an identity perspective, it may involve dozens of separate authorizations.
Without careful design, those authorizations become difficult to understand, difficult to audit, and even harder to revoke.
Identity lifecycle becomes just as important as identity creation.
Who approves a new AI agent?
Who sponsors it?
Who reviews its permissions?
Who rotates its credentials?
Who disables its access when the project ends?
Organizations already have mature answers for employees leaving the company.
Many have no equivalent process for AI agents.
North sees this as one of the biggest governance gaps emerging today.
The challenge isn't issuing identities.
The challenge is remembering that every identity eventually needs an owner.
Some argue that organizations are overthinking the issue.
After all, applications have used service accounts for years. APIs authenticate every second. Automation platforms already perform privileged actions without human intervention.
Why should AI agents be treated differently?
It's a fair question.
The answer lies in autonomy.
Traditional automation follows predetermined workflows.
AI agents decide how to achieve objectives within defined boundaries.
They select tools.
Chain actions together.
Adapt to changing information.
Interact across systems.
The identity supporting that behaviour deserves governance proportional to its flexibility.
Greater autonomy demands stronger identity controls, not weaker ones.
This also changes incident response.
Imagine an AI agent initiating a transaction that should never have occurred.
The forensic investigation now has to answer several questions.
Which identity authenticated?
Which tools were called?
Which permissions allowed the action?
Who approved those permissions?
Was the behaviour consistent with the agent's intended purpose?
If those answers cannot be reconstructed quickly, organizations face operational, regulatory, and reputational consequences long before they determine whether the AI itself behaved incorrectly.
Canadian organizations already operate within privacy and accountability frameworks that reinforce these expectations.
The federal Directive on Automated Decision-Making requires governance proportional to impact.
Quebec's Law 25 strengthens transparency and accountability for automated processing.
Financial institutions already maintain extensive identity governance because regulators expect organizations to know who accessed sensitive systems and why.
AI agents don't remove those obligations.
They make them more important.
North would argue that organizations are asking the wrong first question.
Instead of asking whether an AI agent needs credentials, they should first ask whether they're prepared to govern another enterprise identity that may eventually become more active than many human employees.
That shift changes everything.
The safest approach is not to avoid AI agents.
It is to govern them with the same discipline organizations already apply to privileged administrators, contractors, service accounts, and machine identities.
Each agent should have a unique identity.
Clearly defined ownership.
Minimal permissions.
Continuous monitoring.
Regular access reviews.
Credential rotation.
Documented retirement procedures.
Those principles are familiar because they already work.
They simply need to be extended into a future where some of the busiest identities inside an organization no longer belong to people.
AI agents may never request a password reset or complete annual security awareness training. They won't forget their credentials or leave for another job.
But they will authenticate.
They will access critical systems.
They will make decisions using the permissions they've been granted.
And when something eventually goes wrong, nobody will ask whether the identity belonged to a person or a machine.
They'll ask the same question security teams have always been expected to answer:
Who approved this access, and why?