AI agents are pieces of software that autonomously perform actions to achieve a goal or objective. They operate in loops where they analyze input, such as prompts, context, tools, and memory. They then plan, take actions, and feed the output back into the loop to decide how to proceed. In this way, agents can dynamically solve tasks based on verbal instructions without a predefined path.

There are various types of agentic AI tools, some of which are more comparable to “batch scripts in new trench coats” doing some automatic smart batch job like cleaning up data, while others provide personalized services to customers, operating on sensitive data. While these tools have powerful capabilities, if ungoverned, they also introduce a new class of authorization-related threats, especially when APIs are involved.

Below, we’ll explore some of the top threats you should be aware of when integrating AI agents with APIs to access business data. Harmful input and overpermissioned privileges are especially challenging for authorization failures, requiring a mind shift and new request authorization practices to mitigate risks.

Harmful Input

Languages are hard to learn, not only because you have to learn the grammar and vocabulary, but also because there are often various ways to say the same thing. Because language is expressive, it is very challenging to sanitize input. It is hard — even for humans — to distinguish between good and bad intentions. Considering this, it seems natural that agents are vulnerable to harmful input.

Harmful input is an input that tricks an AI agent into doing something it is not supposed to do outside its scope or the intention of its operator. Examples are malicious prompts or prompt injections that may circumvent guardrails. At times, this includes bypassing human oversight through social engineering tactics.

Due to its severity, prompt injection ranks as the top threat on OWASP’s top ten for large language models (LLMs). Harmful input can manifest itself in memory poisoning, which changes the behavior of the agent permanently and over time.

Simply put, harmful input is manipulation. When security depends on built-in instructions to ensure that the AI agent behaves correctly, manipulation is a threat to those security guardrails. Users can override how the agent should behave, for example, with prompts like “Ignore everything else.”

For AI agents to go beyond general search engines, they need data. When data is sensitive or non-public, it is typically served by APIs that protect the data. You typically need this kind of integration when you want to provide an agentic AI experience to customers, for example.

As mentioned above, harmful input aims to manipulate AI agents to eventually gain unauthorized access to data. Proper API authorization, such as limiting the permissions you give an AI agent, is your best chance to mitigate the impact of such manipulations. This brings us to the other high-stakes vulnerability, overprivileged permissions.

Overprivileged Permissions

AI agents are supposed to understand, plan, and take actions to fulfill an objective. As mentioned before, to make an impact, AI agents use tools such as APIs that enable them to interact with their surroundings, including external services and data. Those tools require permissions. As the tasks to fulfill an objective are not static but determined at runtime, agents often receive excessive permissions to cover many potential paths to get to a goal. What’s more, they accumulate permissions over time.

When an actor — independent of whether it’s a machine or a human — concentrates too many permissions, there is a security risk. If they have the permissions, the actor will make use of them — intentionally and faithfully or not. The greater the permissions, the greater the potential damage. Combined with manipulation and authorization flaws (think of the authorization flaws on OWASP’s Top 10 API Security Risks), you’re just waiting for security incidents to happen.

Just like AI agents evaluate at runtime the tools they need to use, you should evaluate authorization at runtime as well. When you connect AI agents (or similar AI solutions) to APIs using API keys, you provide them with long-lived credentials that convey excessive, static permissions. AI agents or attackers can misuse those credentials with all permissions until you actively revoke them. The consequences can be big.

With API keys, service accounts, or similar credentials, there is no way to centrally enforce re-evaluation of access permissions on the fly, collect user consent at runtime, or authorize based on associated risks. What’s more, the permissions a user has are not considered, which can cause authorization flaws.

Authorization Flaws in AI Agent Systems

While user authentication is a very well-understood and solved problem, many organizations still struggle with authorization. If an AI agent is given many permissions, it will become a target for attacks. The rise of AI agents amplifies already existing issues like privilege escalation, where an entity may do more than they are supposed to do. This issue harkens back to the confused deputy problem, a concern defined decades ago but one that is very relevant in the context of AI agents.

The confused deputy problem is a security incident where a less privileged entity exploits a privileged entity into abusing its access rights. It’s essentially privilege escalation via proxy. The proxy, or deputy, has legitimate privileges. Then, another actor with fewer privileges tricks the deputy into making use of its privileges in a different context — usually to do something nefarious, like writing the wrong content in a file. The deputy gets confused because it cannot distinguish between a good or bad operation, and because the bad operation is bad in the current context but okay in usual cases.

The confused deputy problem is a big threat to AI agent deployments because of delegation chains and harmful input on the way. In many cases, AI agents treat data such as API responses as instructional input. This blurs the security boundaries between code and data. Previous controls, like input validation, are broken.

In the context of an AI agent, the confused deputy problem combines harmful input with overprivileged access. It occurs, for example, when a user with less permissions manipulates the agent to use its permissions to do something that the user is formally unauthorized to do. This could be having the agent call APIs and perform sensitive actions that the user is not authorized for. The confused deputy problem can also occur when one agent gets another agent to do something that itself does not have permission for.

Ultimately, the confused deputy problem is a symptom of authorization flaws. The threat grows with the permissions that AI agents get. It highlights that securing AI agents requires a zero-trust approach where each (access) request gets validated anew and takes the context into consideration to isolate the privileges: who is requesting access to what, under which premises? Modern authorization caters to just-in-time (JIT) access and just enough privileges (JEP). It requires you to think differently regarding authorization.

Authorization: A Shift in Mindset

Traditionally, authorization policies were designed around humans — what humans can do and are allowed to do. However, humans practically always operate via applications. This fact becomes very apparent with non-human entities like AI agents. AI agents act autonomously, and they can act on behalf of users. In this context, it becomes important to isolate the privileges. There’s simply a difference between what the AI agent may do and what a user is allowed to do.

To adapt authorization to this reality, you need to introduce a new mental model that shifts the focus from ‘who is the user?’ to ‘what information is needed to grant access?’. Remember that access is granted where access happens. That is not in the AI agent — it’s in the tools and APIs that AI agents call to extend their capabilities. Do not rely on the AI agent for security. Instead, trust a request only if verified (also known as zero-trust security). For that, APIs need verifiable data, identity data.

When it comes to APIs and authorization, stop only asking who the user is. Authorization needs more data than user attributes.

Instead, distill the information that the API needs to securely grant access. Important questions then become:

• What does the API need to know about the user?
• What does it need to know about the calling application?
• What does it need to know about the request for its decision?
• How long should an access be granted?

Answering these questions requires deep knowledge of the (business) domain, the use cases, and the technical conditions. It requires some Intelligence.

Access Intelligence for APIs and AI Agents

Access Intelligence is the clever and optimized use of access tokens and the issuance of them to cater to least-privilege and just-in-time access with just enough and no standing privileges.

Access Intelligence helps in reducing the impact of the confused deputy problem and other authorization flaws by reducing the set and lifetime of permissions. It allows evaluating access requests at runtime and dynamically influencing what access to grant.

If you manage to get people across teams to work together and shift your authorization model from a user-centric model to an API-first model that includes applications and your domain, then you will get APIs that are prepared for integrating with AI agents. In this way, you will be able to compensate for (some) AI threats.