Top Risks of Using AI Agent Identities

AI agents change the security equation when they are connected to real systems. A chatbot that gives a bad answer can damage trust. An agent that can call tools, access records, use credentials, or trigger workflows can damage data, accounts, infrastructure, and business operations.

Some of the risks are familiar: excessive permissions, long-lived credentials, weak user verification, sensitive data exposure, and poor visibility. Others come from the way agents interpret instructions, retain context, and chain actions across tools. The risks become harder to contain when agents can act asynchronously or operate on behalf of different users.

That makes identity and access one of the most important control points, even when the underlying risk starts somewhere else. Security teams need to understand which agent is acting, what it can reach, which user context applies, and how quickly access can be limited or revoked.

Let’s look at the top risks of using AI agents in production environments.

1) Overpermissioned Agentic Identities

AI agents are finding success as support chatbots, as they are able to analyze conversational context and provide better answers than keyword-based lists of options. Most of these agents only perform triage for live agents (real humans). However, we are starting to see AI agents able to perform support actions on the user’s accounts.

The simplest approach would be to provide the support agent with admin permissions, then rely on system prompts to limit what the agent can do depending on who they are talking to:

But as we learned from this programming humor, prompts are not reliable enough for enforcing permissions. Such a setup opens the door to users escalating privileges and performing actions they shouldn’t, or the agent leaking data from other accounts.

Solutions:

• • Implement permissions at the tool level.

• • Provide agents with a minimal set of permissions tailored to the user.

• • Limit the scope of agent tools to reduce their attack surface.

OAuth 2.0 token exchange can help issue short-lived, scoped access for a specific agent action, user context, or downstream resource, instead of giving the agent standing credentials. 

2) Broken User Verification in Agent Workflows 

The next challenge is to properly identify users.

Support agents often have to deal with unidentified users. For example, because they call over the phone, or because they want to regain access to their accounts. The standard is to verify the user’s identity by asking for some personal identifiable information (PII). The same applies to AI agents.

However, AI agents are especially susceptible to impersonators, as they often lack the context and mechanisms to identify suspicious requests and escalate them for human review.

In mid-2026, attackers reportedly abused Instagram’s chat support to change the email address on any account, with IP-based geolocation serving as the only identity check. 

Solutions:

• • Use proper authentication when possible.

• • Perform the checks through secondary channels (email address, phone, etc…)

• • If there’s no alternative, collect enough pieces of PII to identify the user with certainty.

• • Escalate to live-agents on sensitive actions.

Keeping humans in the loop can also help identify areas where the agents struggle to make the right decisions and improve their training.

3) Long-Lived Credentials & Permission Drift

By their nature, AI agents need access to a broad catalog of resources to complete complex tasks. As they evolve, they may gain access to more services to perform their tasks better. This access may be stored as:

• • Static API keys

• • Database credentials

• • SSH keys

• • OAuth refresh tokens

If those credentials persist over time, a compromised agent can become a path into every connected service those credentials can reach.

Permissions can also drift as both the agent and the surrounding environment change. For example, an agent may have read access to a folder that originally stores development test data. Over time, that same folder may start storing sensitive customer or business data, while the agent’s access remains unchanged.

Credential persistence and permission drift are not new problems. Security teams have dealt with similar issues for years, such as employee access that remains active after a role change or departure. Agents add a new layer of risk because one agent may be able to operate across many systems, tools, accounts, and user contexts.

Solutions:

• • Use OAuth 2.0 token exchange where possible to issue short-lived, scoped access for a specific task, user context, or downstream resource.

• • Use policy-brokered JIT access for services that do not natively support short-lived access.

• • Avoid giving agents standing credentials whenever access can be requested, scoped, and approved at runtime.

• • Rotate tokens, SSH keys, and other credentials that still need to exist.

• • Audit agent access regularly and re-evaluate permissions as tools, data, and workflows change.

4) Visibility Without Runtime Enforcement

Logs and dashboards help teams understand what agents are doing. But visibility alone does not stop an agent from deleting data, calling the wrong tool, or using access outside the intended context. Agent access needs a policy decision before the action executes.

As agentic identities are able to act independently and autonomously, they can run amok without proper oversight – like what reportedly happened in early 2026 to a director at Meta’s Superintelligence Labs, whose OpenClaw deleted all the emails from her Gmail account.

This was not purely an identity failure. It was a control failure: the agent had real access, and the approval boundary lived in the prompt instead of the execution path.

• • The directive to “never to act without confirmation” was provided in a prompt rather than using the agent’s tool settings.

• • The context window compaction process, which removes older instructions to manage memory, removed this directive.

How enforcement can help:

• • Runtime policy controls should evaluate agent tool calls before execution and either allow, deny, step up, or require human approval based on the agent identity, user context, requested action, resource, and policy.

• • Agent access should be brokered through a central policy layer, so teams can issue short-lived credentials, enforce conditions, and revoke access without hunting through individual tools and scripts. Think of it as an Andon cord for agent access: when the behavior is wrong, security can stop the action path instead of watching the damage appear in logs. 

5) Related AI-Agent Risks That Can Become Access Risks 

Agents are highly susceptible to manipulation that can bypass your authorization efforts.

In particular, beware of prompt injection, the technique of forcing a large language model outside its guardrails. A famous case was Chipotle’s support bot being tricked into returning some code.

Another dangerous technique is data, model, and tool poisoning, in which attackers may also poison the data, tools, or retrieval sources an agent relies on. If the agent trusts those inputs and has access to downstream systems, bad context can turn into unauthorized action.

Solutions:

• • If you have control over the client (i.e., a chatbot on your website), separate instructions from untrusted data, filter obvious malicious inputs and outputs, and enforce authorization outside the model. Prompt filtering is useful defense-in-depth, not the access-control boundary. 

• • Leverage OAuth token exchange and implement permission checks at every step.

Classic Workload Risks Still Apply 

AI agents still run as software. They execute in cloud environments, call APIs, use credentials, interact with data stores, and depend on infrastructure. The same workload security problems still apply, but agent autonomy can increase the blast radius. 

Take special care to:

Data used for training: Training is a process extremely difficult to audit and is very hard to reverse. Be aware of the data used to train the model, as it may be personal or confidential. 

Access to sensitive data: The same happens when granting your agent access to data that is particularly sensitive. For example, it may seem logical to grant an internal chatbot access to your company’s CRM. But if this chatbot is compromised, this may result in an attack with a huge blast radius.

Leaking credentials – LLMJacking:. Stolen LLM API keys can be used for unauthorized inference, data access, or costly consumption of the victim’s account. 

Denial of service: In the AI era, you don’t need a botnet to overrun an agent with requests. Sometimes, attackers can craft specific inputs that consume huge amounts of resources: spawn additional agents, force long reasoning chains, or make tool calls without a termination condition.

Conclusion

The main risks associated with agent identities stem from the combination of non-deterministic behavior and overly permissive access. When agents are granted broad credentials to enable autonomy, a bad instruction, compromised context, or mistaken action can affect real systems.

Some of these problems are not new. Security teams have dealt with credential leakage, permission drift, and excessive access in legacy workloads for years. AI agents increase the stakes because they can act across tools, data, accounts, and user contexts with less predictable execution paths.

To reduce the attack surface, put safety constraints in the system rather than relying on prompts alone. Use short-lived credentials, JIT access, and agent identity controls to limit what agents can reach, reduce permission drift, and make access easier to revoke when something goes wrong.m