AI Agents: Why Authentication Alone Cannot Protect Them

Many organizations typically implement a tool called a 'gateway' to manage the entry point of communications as their first security measure for AI agents. However, while gateways are easily selected as the starting point for security measures, they are also the least suitable control for actual operations. The fundamental reason is that the mechanism for identifying 'who is accessing,' which the gateway should assume, is not yet in place in many operational environments.

This problem is not merely theoretical; actual security incidents demonstrate it. In June 2025, the US cybersecurity agency CISA added a vulnerability in the AI gateway software LiteLLM to its list of known exploited vulnerabilities. This vulnerability allowed command execution on the host OS through the gateway and could be exploited without authentication when combined with another vulnerability. Furthermore, 7 CVEs were published within one month for LiteLLM, demonstrating that the gateway itself—which many organizations select as the 'first line of defense' for AI agent protection—can become a serious attack target.

So in what order should security measures be built? There is a perspective that gateway control should be positioned as the 'fifth control' rather than the 'first move.' AI agent security is built on chains of dependencies, and each control depends on context generated upstream. Without information on the foundation for control—'which agent is operating,' 'who delegated the task,' 'which task is being executed,' and 'which credentials are being used'—the gateway can only block explicit policy violations and overlooks operations that are technically permitted but operationally inappropriate.

Here is a concrete risk example. For instance, if an agent responsible for financial reconciliation attempts to modify records in production data, the gateway can authenticate the user token and verify the API call. However, the gateway cannot see that the request originates from the agent, that the agent has only limited functionality, or that the operation is part of a tool chain triggered by untrusted external data. Although the credentials are valid and the API call is permitted, the operation deviates from its intended purpose. Costly controls are functioning for only a small portion of the overall picture.

Additionally, restricting an agent's authority within the scope of the responsible person's authority is a valid principle but is not sufficient. Even when 20 agents operate with the authority of a single user, each requires its own unique ID, audit log, behavioral profile, and revocation path. Setting an upper limit on authority and establishing individual attribution are entirely different problems.

This challenge is deeply related to the reality of retrofitting existing systems. Many organizations already have some form of IAM (Identity and Access Management) system in operation, and the order in which AI agents are integrated into it becomes a question. Theoretical security maturity models tend to enumerate controls needed in the future but fail to address the more difficult practical question of 'order of application to existing environments.'

As AI agent adoption expands, security discussions are shifting from 'what to implement' to 'in what order to build.' Gateways are an important control, but their effectiveness is limited unless the prerequisite conditions for their operation—agent identification, delegation relationship tracking, and behavioral context recording—are established first. Looking toward production operations for agents, the perspective of 'dependency-based phased deployment' will become increasingly important in future security design.