7 questions for secure AI agents in IAM

AI Agent #132 is active. Who does it belong to?

AI Agent #132 logs into your identity provider every day. It retrieves tokens, calls APIs, and reads data from multiple systems. It has four roles, a client secret, and access to areas that a team authorized for a pilot project several months ago.

The pilot project has long since ended. The person who created the agent now works in a different department. The secret has never been rotated since it was set up. And no one in the company could immediately say who is responsible for this agent.

This is not a contrived extreme example. Such cases arise wherever AI agents are introduced faster than identity processes can keep up. This article shows which seven questions you should ask for every agent in your IAM and what the answers should look like when everything is in order.

‍

AI agents are identities, not configuration details

Non-human identities (NHIs) are all identities that authenticate and are authorized without being human. This includes traditional service accounts, API clients, CI/CD pipelines, RPA bots, and workloads. AI agents are the newest and fastest-growing group among them.

Agents differ from traditional technical accounts in three ways:

• They decide for themselves which interfaces to call. An integration client always does the same thing. An agent chooses different tools and data sources depending on the task.
• They operate in two modes. Some agents work autonomously with their own identity, typically via the OAuth 2.0 client credentials flow. Others act on behalf of a user: the user authorizes the agent, for example via the authorization code flow, and the agent receives a token with that user's permissions. If the agent needs to pass the request on to other services, OAuth 2.0 token exchange (RFC 8693) is often used. Many agents do both.
• They are created in a decentralized manner. Departments often set up agents themselves without the central IT department knowing about every single one.

This leads to a fundamental principle: every agent needs its own unique identity. If it shares access credentials with a human or a shared account, it becomes impossible to distinguish who triggered an action in application audit logs.

‍

The core problem: agents have no lifecycle trigger

There are well-established processes for human identities. Onboarding, department transfers, and offboarding are recorded in the HR system, and the IAM reacts accordingly: creating accounts, adjusting roles, and revoking access. This joiner-mover-leaver model works because there is a reliable trigger.

With agents, this trigger is missing. No HR system reports that a pilot project has ended or that an agent is no longer needed. Without a consciously established process, an agent is created once and never touched again. Permissions are added, but rarely revoked.

The fact that this is exactly where the greatest risk lies is confirmed by the OWASP Non-Human Identities Top 10 (2025)The top issue is improper offboarding—NHIs that aren't deactivated even though they are no longer needed. Other common issues include insecure authentication, over-privileged NHIs, and long-lived secrets. You can evaluate all four points by asking the following questions.

Seven questions every agent must answer

The following questions apply regardless of which identity provider you use. The summary at the end of this section outlines the warning signs and the target state.

1. Who is responsible?

An agent without an owner is never reviewed. No one notices when it becomes redundant, and no one reacts if it starts behaving suspiciously.

Target state: Every agent should have a designated owner, ideally a team with a specific point of contact. If this person changes roles or leaves the company, the agent is automatically flagged for review. This ties agent offboarding to the existing offboarding process for employees.

2. Is the agent actually still in use?

An enabled but unused agent is a security risk. Its credentials remain valid and its permissions stay active, even though it is no longer needed.

Target state: The last activity for every agent should be visible. After a defined period of inactivity—for example, 90 days—the owner is notified and the agent is subsequently deactivated. Deletion should only occur after an additional grace period, allowing for the reversal of any accidental deactivations.

3. When was the secret last rotated?

Experience shows that secrets often end up where they don't belong: in configuration files, repositories, tickets, or logs. The older a secret is, the more copies of it usually exist, and the more likely a leak becomes.

Target state: Secrets should be rotated regularly, with a short transition period where both the old and new secrets are valid. This ensures the agent continues to function without interruption during the switch. Even better is to avoid shared secrets entirely, which leads to the next question.

4. How does the agent authenticate?

With a shared secret (client secret), both the agent and the identity provider know the same key. In common methods like client_secret_basic and client_secret_post, the agent transmits this key with every token request. Anyone who intercepts the secret can impersonate the agent.

Target state: Asymmetric methods, which have long been the standard for authenticating human identities. With Private Key JWT (RFC 7523, defined as private_key_jwt in OpenID Connect), the agent signs a short-lived JWT assertion with its private key for every token request. The identity provider only knows the public key; the private key never leaves the agent. Alternatively, the agent can authenticate via mTLS using a client certificate (RFC 8705). RFC 8705 also allows issued tokens to be bound to the certificate. If the API verifies this binding, an intercepted token cannot be used without the corresponding private key. DPoP (RFC 9449) offers comparable protection without requiring mTLS.

5. How long do its tokens live?

Access tokens are generally bearer tokens: whoever possesses the token can use it. Self-contained JWTs are usually verified locally by APIs without checking back with the identity provider. Revocation only takes effect once the token expires. With a 24-hour lifespan, a stolen token remains valid for up to a full day.

Target state: Short lifespans in the range of minutes, for example, 5 minutes. For agents using the client credentials flow, this is negligible, as they can simply request a new token when needed. For critical systems where immediate revocation might be necessary, APIs should additionally verify the presented tokens with the identity provider via token introspection (RFC 7662) for every access attempt.

6. Are its permissions time-limited?

Agents tend to accumulate permissions. A role is added for a project, then another for a test. Permissions are rarely revoked because no one wants to risk breaking the agent. The result is over-privileged identities that have far more access than they actually need.

Target state: Every role and group assignment has an expiration date. Extensions are a conscious decision by the owner, not a default setting. Additionally, token scopes and audiences are restricted to the APIs the agent actually requires.

7. Are there any suspicious failed attempts?

Frequent authentication failures usually have one of two causes. Either the configuration is faulty, for example, because a rotated secret did not reach the agent. Or someone is attempting to log in as an agent using incorrect or stolen credentials. Both scenarios require a response.

Target state: Authentication errors per agent are analyzed. Once a threshold is reached, the owner is notified. A central activity log shows when and how often the error occurred.

The seven questions at a glance

What NIS2 and ISO 27001 have to do with it

Access control requirements also apply to agents. In Germany, the NIS-2 Implementation Act, which has been in effect since December 6, 2025, requires essential entities to have access control concepts in place (§ 30 para. 2 no. 9 BSIG). ISO 27001 requires managing identities throughout their entire lifecycle and regularly reviewing access rights. In an audit, this means you should be able to demonstrate for every agent who is responsible, what rights it has, until when, and what it did last.

‍

How to get started

You don't have to fix all your agents at once. Three steps are enough to get started:

1. Create an inventory. List all clients through which agents obtain tokens and cross-reference the list with token logs. You can usually deactivate inactive agents immediately.
2. Prioritize by risk. Start with agents that have extensive permissions, a shared secret, and long token lifetimes. Go through the seven questions for these agents one by one.
3. Establish rules for new agents. No new agent without an owner, without time-limited assignments, and without key-based authentication.

The most time-consuming part is not the one-time cleanup, but the ongoing review. Anyone doing this with scripts and spreadsheets will have outdated data again within a few months.

‍

New in preview: Agents in Bare.ID

That is why we have built the answers to the seven questions directly into the Bare.ID interface. We will be presenting the new agent management at it-sa 2026.

A dedicated area for non-human identities. Under "Agents," you will find all non-human identities separated from user accounts. The detailed view shows the owner, the linked application, roles and groups, the last activity, and the number of tokens issued in the last 30 days for each agent. Below that, you will find authentication methods and token lifetimes.

Security analysis. Every agent receives a security analysis, which is also displayed as a score. Evaluations are based on factors such as permissions, credentials, and usage, following the exact criteria outlined in this article: owner, activity, secret age, authentication method, token lifespan, temporary assignments, and failed authentication attempts. Each finding is categorized by severity, making it easy to quickly identify problematic agents.

‍

Transparent activity. The activity log shows what an agent has done recently, broken down by event type, such as API login, token validation, or token exchange. Failed login attempts are just as visible as successful ones.

This allows you to turn an agent with a poor security score into one with a top rating, step by step: key-based authentication, short token lifespans, temporary assignments, and a clearly defined owner.

Bare.ID is based on Keycloak. Keycloak represents agents as clients with service accounts, but it does not provide a consolidated view of owners, usage, and risk per agent. This view has been added via the Bare.ID agent management interface. Agents continue to authenticate using standard OAuth 2.0 and OpenID Connect protocols.

How many agents are you running?

Most teams underestimate the number of non-human identities they have until they create an inventory for the first time. If you would like to see how your agents measure up against these seven questions, let’s take a look together.

‍

‍