Identity and Access Management for AI Agents

In companies, every employee has a user account with a password. And each account is only allowed to do certain things: accounting can see invoices, but not personnel files. This management of accounts and permissions is called identity and access management, or IAM for short. For some time now, however, it is not only humans working in companies but also programs that carry out tasks independently. Such programs are called AI agents: they are given a goal, plan the necessary steps themselves, and in doing so access emails, databases, or online services. Identity and access management for AI agents means that these programs, too, receive their own account with clearly limited permissions.

Why an agent must not be a normal user account

In practice, developers often take a shortcut. The agent is simply given a human’s credentials and acts in their name. This is convenient, but dangerous. Because afterward it can no longer be distinguished whether a transfer came from the employee or from her assistant program. And the agent inherits all of that person’s rights, including ones it would never need.

On top of that comes a scale problem. A human works eight hours a day and clicks perhaps a few hundred times. An agent can run around the clock and make thousands of requests per minute. If it goes off track or is manipulated, it can cause in minutes the kind of damage that would take a human weeks. Already today, many companies have significantly more such machine accounts than human users.

There is also a form of attack that does not exist in this way for humans. It is called prompt injection: a website or email contains hidden instructions that the agent mistakes for a genuine task. It then dutifully follows them. Tightly set permissions are the only reliable brake when this happens. An agent that is only allowed to read cannot delete anything even after a successful manipulation.

Credential, permission, and log

The first building block is identity. The agent does not get a password but a cryptographic certificate or a key. This is a very long sequence of numbers that is practically impossible to guess. With it, the agent identifies itself to every system it wants to use. It is important that this identity belongs to the agent and not to its principal.

The second building block is permissions. The common approach is the principle of least privilege: the agent gets exactly the permissions its task requires, and not a single one more. An agent that coordinates appointments may read and write the calendar, but may not open the payroll system. Frequently, the credentials are also time-limited and valid for only a few minutes. If the key expires, it is worthless to an attacker.

The third building block is traceability. Every action is logged, together with the question of on whose behalf the agent acted. Experts call this chain of human, agent, and action delegation. For particularly sensitive steps, such as payments above a certain amount, a human must additionally give approval. And there needs to be a kill switch that immediately invalidates an agent’s identity.

From the corporate network to the shopping assistant

The topic is most visible in companies. When a company connects an AI assistant to its internal documents, access management decides who gets which answers. Without clean boundaries, the assistant might quote the management’s layoff plans to an intern. Identity software providers such as Microsoft, Okta, or Ping Identity have therefore brought dedicated products for agent identities to market.

The principle also appears in everyday life, usually unnoticed. When you allow an app to read your calendar but not your contacts, that is the same idea on a small scale. With shopping or travel assistants meant to book things independently, the question becomes more concrete: how much money is the program allowed to spend before it has to ask?

In the news, you often encounter the term in connection with security incidents and regulation. A common misconception is that a secure language model also results in a secure agent. That is not true. The model decides what the agent wants to do; access management decides what it is actually allowed to do. Only this second layer limits the possible damage.