[Contributed Article] AI Agent Security Is Breached in Connected Authority, Not the Model

Lee Yong, Product Cheif Director

In the era of AI attacks, AI security begins with agents knowing connected assets and permissions.

As artificial intelligence (AI) becomes deeply integrated into corporate business systems, the perspective on security is also changing. It is now difficult to judge the level of security solely based on how secure the responses an AI model generates. New security challenges have emerged regarding what information AI agents read, which systems they connect to, and to what extent they can perform actual tasks.

We examine how to manage assets and permissions connected to AI agents that have entered the organization.

These changes are also appearing in the financial sector. Following improvements in network separation regulations, the use of AI in asset management, screening, and customer consultation is expanding, and there is a growing trend of AI agents performing multiple tasks sequentially or integrating with existing business systems.

AI security must not be limited to protecting the model itself. The scope of management must extend to the data, business systems, APIs, service accounts, and authentication tokens accessed by the AI. Ultimately, security in the AI era also begins with securing visibility into assets.

The Speed of Attack and Defense Changed by AI

AI is accelerating the speed of existing cyber attacks while simultaneously creating new invasion pathways.

The fundamental principles of attacks, such as phishing, vulnerability exploitation, account hijacking, and supply chain breaches, have not changed significantly. However, attackers have been able to leverage AI to identify a large number of targets at a lower cost and repeatedly test various attack methods.

Changes are also emerging in the field of vulnerability detection. 'Big Sleep,' an AI agent jointly developed by Google DeepMind and Google Project Zero, has been utilized to detect unknown vulnerabilities in actual software. Google explained that Big Sleep contributed to discovering vulnerabilities and proactively responding to vulnerabilities with a high potential for exploitation by linking them with threat intelligence.

What is important is not the fact that AI discovered vulnerabilities itself. It is that as both attackers and defenders utilize AI, the time required for everything from vulnerability discovery and analysis to assessing exploitability, patching, and verification is rapidly shortening.

It is difficult to cope with such rapid changes relying solely on existing periodic vulnerability scans and reactive patching. Companies must continuously monitor the status of externally exposed assets and vulnerabilities, and simultaneously assess the risks associated with assets connected to AI services.

Although both operate within the same four-stage framework, the operational velocity of human agents and autonomous agents diverges fundamentally.

Risk of legitimate documents being turned into malicious commands

A representative threat to watch out for in an AI agent environment is 'Indirect Prompt Injection'.

This is an attack method in which, instead of the attacker directly inputting malicious commands into the AI, malicious instructions are hidden within documents or external content that the AI reads during the course of its work.

In the past, emails, web pages, code comments, and business documents were primarily information read by humans. However, the situation has changed as AI agents have begun reading these materials and even performing actual tasks.

This is because sentences included in external documents can be interpreted by AI as execution instructions rather than simple information.

For example, let's assume a development support agent reads an issue in a public code repository. If an attacker inserts text into that issue that induces the agent to search for an internal configuration file, the agent may mistake this for a legitimate work instruction.

In this case, if the agent has extensive privileges to access the internal code repository and file system, a single external document can become a pathway to access internal confidential information.

The international web security organization OWASP identifies prompt injection and excessive agent privileges as major security risks for Large Language Model (LLM) applications.

It is difficult to respond to such attacks using only existing security tools. Static Application Security Testing (SAST) identifies vulnerabilities in source code, while Software Configuration Analysis (SCA) checks for risks in open-source components. Data Leakage Prevention (DLP) and Identity and Access Management (IAM) also handle their respective security domains.

However, the problem of malicious instructions embedded in normal documents altering AI behavior and consequently using excessive privileges is difficult to fully resolve with individual security tools alone.

Therefore, companies must treat external documents, emails, API responses, and tool execution results read by AI as untrusted inputs by default. At the same time, they must clearly distinguish the boundary between information that AI can read and tasks that it can actually execute.

Data or Directive: If AI Fails to Police the Boundary, It Falls

The problem is the connected authorization design rather than the MCP itself.

The Model Context Protocol (MCP) is a connection method that enables AI agents to interact with external systems and tools. Through this, AI can access file repositories, code repositories, email, Customer Relationship Management ( CRM ), databases, cloud management systems, and more to perform actual tasks.

The problem is not the MCP technology itself, but the scope of authority granted during the connection process.

Granting authentication tokens usable across multiple systems and extensive execution privileges to AI agents that read untrusted external content increases the likelihood that minor input manipulations will lead to large-scale security incidents. In particular, if a single service account or authentication token is shared across multiple systems, a breach by a specific agent can spread to other business systems.

Companies must identify which external content AI agents read, which internal systems they access, and which authentication tokens they use. Furthermore, they must be able to distinguish permission scopes—such as reading, writing, deleting, and external transmission—and verify actual tool calls and data access history.

To this end , it is necessary to include AI agents, MCP servers, API gateways, service accounts, authentication tokens, data repositories, etc., within the scope of existing IT asset management.

This means that AI agents should not be viewed as a single piece of independent software, but rather managed as a single network connecting various assets, accounts, and services.

A Single Credential, an Expanding Blast Radius

AI-connected assets must be integrated into the existing vulnerability management system.

To reduce the security risks of AI agents, a consistent system must be established, ranging from asset identification and risk assessment to execution control and action history management.

The first is to include AI-related assets within the scope of existing asset management.

It is necessary to identify not only AI models but also external AI services, coding aids, MCP servers, plugins, vector databases, Search Augmented Generation (RAG) document repositories, integrated APIs, and service accounts. So-called Shadow IT and Shadow APIs, such as unauthorized AI tools and unmanaged API integrations, are also subject to inspection. It is crucial not to stop at creating a separate list of AI assets but to connect them with existing server, application, network, and cloud asset information.

The second is a risk assessment that reflects AI connectivity.

Not all vulnerabilities pose the same risk. Vulnerabilities in databases connected to AI agents accessing customer information, or in systems with actual service deployment privileges, can have a greater impact than vulnerabilities in general internal development environments.

Therefore, the priority of measures must be determined by comprehensively considering not only the Common Vulnerability Assessment System (CVSS) score but also asset importance, external exposure, data sensitivity, access rights, and the relationship with AI agents.

The third is to apply the principle of least authority and human approval procedures.

Dedicated accounts must be issued for each agent, and read, write, delete, and external transfer permissions must be differentiated. In particular, explicit human approval and recovery procedures are required for high-impact operations such as the external transfer of customer information, payments, contract changes, operational system deployments, and account permission changes.

The Financial Security Institute also prepared the 'Draft Security Evaluation Standards for AI Agents in the Financial Sector' in October 2026. These standards propose execution authority, isolation, human approval, verification of the scope of work, and kill switches to halt autonomous execution as inspection targets. Following pilot verification at the end of the year, the plan is to expand their application as official inspection standards in 2027.

The fourth is to secure the history of corrective actions and audit evidence.

When a security incident occurs, it must be possible to identify which agent read which information, which account accessed which system, and which tools were executed. Managing the entire process—from vulnerability discovery and remediation timing to responsible personnel, approval records, and re-inspection results—is essential to quickly assess the scope of the incident's impact and enable a responsible response.

From Visibility to Remediation: The Four Stages of AI Security   

The starting point of AI security is asset visibility

Let's assume a scenario where a financial company connects a customer support AI agent to its internal business system.

First, you must identify the agent, MCP server, service account, and API, and record the connection relationships with the system holding customer information. Subsequently, integrate software vulnerabilities and configuration errors collected from various security diagnostic tools into the relevant assets.

Based on this, risks are assessed by reflecting external exposure, asset importance, and AI connectivity, and the person responsible for action and the deadline are assigned. After the improvement, a follow-up review is conducted to verify that the risk has been resolved, and relevant records are kept.

Executives can verify the level of security controls through the asset registration rate, owner designation rate, least privilege enforcement rate, shared token usage status, and high-risk operation approval rate of AI agents and service accounts.

Such integrated management does not replace the control of AI agent execution. Input validation, least privilege, human approval, and emergency interruption measures must be designed and operated separately.

However, if you cannot identify which AI agent is connected to what, it is difficult to even determine where to apply these controls.

As the adoption of AI expands, security questions must also change. It is necessary to verify not only which model to use, but also which assets the model and agents read, which systems they connect to, and what they can execute with what permissions.

Externally exposed assets and unaddressed risks, the interconnectedness of software components and operational assets, and AI agent security ultimately lead to a single challenge.

It involves accurately identifying the assets and risks held by the organization, implementing necessary measures, and continuously verifying the results.

AI 연결 자산은 별도 목록이 아니라 기존 관리 체계 안에서 다뤄야 한다.

AI security is not completed by adding a single new security product.

We must start by extending the existing asset, vulnerability, and remediation management system to a system connected to AI, and combining least privilege and execution controls on top of it.

---

View original text

Electronic Times