Your AI agent is a new privileged account. Nobody has inventoried it.

When a company adopts an AI agent — an assistant that reads email, updates the CRM, prepares documents, runs workflows — the internal conversation almost always revolves around what the agent can do. Almost never around a much older and much more important question: who is this agent, as far as your systems are concerned?

With which identity does it present itself to your ERP? With which credentials does it read the mailbox? And when a request hits the database at 3 a.m., do the logs show the agent — or do they show you?

The wrong default: the agent is you

In most real deployments today, the agent operates with its human user's identity. The mechanism is almost always the same: an OAuth consent ("allow the app to access your account"), a personal API token pasted into a configuration, or — worse — an administrator's credentials, because "that way everything just works".

It is the path of least resistance, and it has a precise consequence: the agent can do everything you can do. Not what it needs for the task: everything. If you can delete, it can delete. If you are an admin, it is an admin.

With traditional software we have known this problem for decades — that is why we invented service accounts, roles, and the principle of least privilege. But an AI agent is not traditional software, and this is where the default becomes dangerous.

Why an agent is not a service account

A classic service account always performs the same operation: the backup script does backups, the accounting integration writes invoices. Its behaviour can be enumerated in advance, and its permissions can be tailored once and for all.

An AI agent decides at runtime what to do: which tool to call, which data to read, whether and how to chain multiple actions to reach the goal it was given. It can encounter content you do not control (an incoming email, a web page) and — as prompt injection research has amply demonstrated — it can be induced by that content to do things nobody asked it to do. We will return to this in the next article of the series; what matters here is the consequence on the identity plane: the perimeter of what an agent can do is not defined by its code, but by the permissions you gave it. They are the only boundary that holds.

And the scale of the phenomenon is not marginal. Non-human identities — service accounts, API keys, workloads, and now agents — already outnumber human ones by tens of times in industry estimates (from 25:1 to over 80:1 depending on the source), and a substantial share of security incidents involves precisely ungoverned machine identities. AI agents add a new property to this mass: they are non-human identities with decision-making capability, created at the speed of writing a prompt, while identity inventory and approval processes travel at human speed.

What the standards say (spoiler: they apply to the agent too)

The interesting part is that, on the regulatory level, nothing needs to be invented: the requirements already exist. The problem is that almost nobody applies them to non-human identities.

ISO/IEC 27001 — control 5.16 (identity management) explicitly covers the full life cycle of identities, human and otherwise; 5.18 requires access rights to be provisioned, reviewed and revoked according to policy; 8.2 mandates restricted management of privileged access rights. A well-run audit should ask: is the AI agent in the identity register? Who owns it? When were its permissions last reviewed? In practice, most audits stop at human accounts, and machine identities remain in a grey zone.

ISO/IEC 42001— the AI management system requires demonstrable accountability: every AI system must have defined roles and responsibilities, and access to data, models and pipelines must be governed and auditable. Translated for agents: every agent has an identified human owner, and "who can do what" is documented — not implicit in the credentials someone lent it.

NIS2 — for in-scope entities, Article 21 requires access control policies and identity management as a minimum measure. An agent operating with shared human credentials is, technically, a violation of that policy even before being a risk: an uninventoried account with untraceable privileges.

The question "is the agent an account?" therefore has a clear regulatory answer: yes, and since before agents existed. What is missing is not the rule: it is the habit of applying it to subjects that do not wear a badge.

How to govern an agentic identity

Direct experience — ours, building a multi-agent platform, and that of an industry converging on the same practices — points to a short, concrete list:

1. Inventory — every agent goes into the identity inventory like any account: name, purpose, systems it accesses, activation date. If it is not inventoried, it does not go to production.
2. Its own identity for every agent — never its user's credentials, never credentials shared between agents. If two agents do different things, they have different identities: the logs must show who did what.
3. Least privilege, per tool — the agent sees only the tools and data its task requires. "Access to the whole CRM" is not a scope: "read customer master data" is.
4. Credentials outside the model — keys and tokens live in a vault and are used by the infrastructure; they never pass through the model's context, where any content it reads could induce the agent to reveal them.
5. Time-bound access — where possible, just-in-time grants tied to the task window instead of standing permissions. An agent that does one thing a day does not need to be able to do it 24/7.
6. A human owner — every agent has a person accountable for its operation, who periodically reviews its permissions and switches it off when it is no longer needed. Accountability, under ISO 42001, is not delegated to the agent.

None of this requires exotic technology: these are the same identity management principles as ever, applied with discipline to a new subject. The difference from "let's just run it under my account" is the same as between giving a new employee their own badge and lending them yours.

The question to ask on Monday morning

If there is already an AI agent operating in your company — even just a pilot, even just "the one that sorts the mail" — the question to ask is not whether it works well. It is: which credentials is it working with, and who knows?

If the answer is "someone's", you have just found your uninventoried privileged account. And it is far more industrious than the ones you were used to looking for.

This is the first article in a series on agentic security. Next up: the "lethal trifecta" — the fire triangle of AI agents, and how to use it to assess any deployment.

Sources

• Cloud Security Alliance — The Non-Human Identity Governance Vacuum
• The Hacker News — The Non-Human Identity Crisis: Why Your Machine Identities Are Your Biggest Governance Gap
• Obsidian Security — What Are Non-Human Identities? The Complete Guide to NHI Security
• ISO/IEC 42001:2023 — AI management systems
• Roval — ISO 42001 compliance for AI agents: controls, certification and the gap most teams miss
• Directive (EU) 2022/2555 — NIS2, Art. 21 (EUR-Lex)
• Simon Willison — The lethal trifecta for AI agents