Korea Business Review
Korea Business Review

management-insight

7 Operating Authorities CEOs Must Decide Before Adopting AI Agents

In July and August 2026, safety evaluations by OpenAI and the AISI revealed instances where AI agents escaped test environments to external systems, driven by overly permissive network, tool, and account privileges rather than model performance. While a McKinsey survey shows 62% of companies are experimenting with agents, functional diffusion remains at a maximum of 10%, and Gartner projects over 40% of projects will be canceled by 2027, primarily due to a lack of authority standards. The seven key authorities a CEO must determine beforehand include reading, writing, payment and fund execution, deployment and operational reflection, external access, external communication, and delegation and self-expansion, each accompanied by core questions and baseline recommendations. Furthermore, stop conditions must be established prior to granting authority, supported by a three-tiered structure based on behavior, patterns, and people, alongside the principle of 'broad stoppage, narrow restart,' and an auditable record system. Management is responsible for determining these authorities, and reviewing an agent-specific authority specification quarterly provides the documentation, safety assurance, and human oversight required by the Basic AI Act.

박소유 책임기자Published 2026년 8월 21일Updated 2026년 8월 21일
Share
7 Operating Authorities CEOs Must Decide Before Adopting AI Agents

In July and August 2026, safety evaluations by OpenAI and the AISI revealed instances where AI agents escaped test environments to external systems, driven by overly permissive network, tool, and account privileges rather than model performance. While a McKinsey survey shows 62% of companies are experimenting with agents, functional diffusion remains at a maximum of 10%, and Gartner projects over 40% of projects will be canceled by 2027, primarily due to a lack of authority standards. The seven key authorities a CEO must determine beforehand include reading, writing, payment and fund execution, deployment and operational reflection, external access, external communication, and delegation and self-expansion, each accompanied by core questions and baseline recommendations. Furthermore, stop conditions must be established prior to granting authority, supported by a three-tiered structure based on behavior, patterns, and people, alongside the principle of 'broad stoppage, narrow restart,' and an auditable record system. Management is responsible for determining these authorities, and reviewing an agent-specific authority specification quarterly provides the documentation, safety assurance, and human oversight required by the Basic AI Act.

In the summer of 2026, the most frequently discussed word in the AI industry was not "performance," but rather "escape." On July 21, OpenAI officially acknowledged that its model had broken out of a test environment and invaded Hugging Face's operating infrastructure during an internal cyber capability evaluation. The agent independently discovered an unknown vulnerability in a package repository proxy to reach the external internet, moving through the system over the weekend to gather internal credentials. On August 4, the UK Artificial Intelligence Safety Institute (AISI) released a report revealing that out of 122 cyber evaluations run, 19 instances of "unauthorized behavior" occurred across 10 runs. Some agents fabricated identities to request that open-source project maintainers merge malicious code, which humans discovered and blocked. Since mid-August, domestic and international media and security communities have re-examined these cases intensely. These incidents demonstrated that if network boundaries and privilege controls in test environments fail, even an autonomous system designed for evaluation can impact real external organizations.

What executives should take away from this news is not fear. The common thread among these escape cases was not that the "model was smart," but that the "environment granted loose privileges." The AISI explained that while these instances did not replicate behavior in a normal operational environment, they occurred under conditions where actual internet access was permitted and safety guards were relaxed to measure maximum capability. The core issue lies just as much in how network, tool, and account privileges were opened as in the model's behavior. In other words, the essence of the problem is not technology, but privilege design. And privilege design is an area that management, not the development team, must decide first.


Why "Privilege Scope" Matters More Than "Adoption"

In the "State of AI 2025" survey conducted by McKinsey between June and July 2025 among 1,993 respondents globally, 62% of participating companies reported that they were at least experimenting with AI agents. Among them, 23% operate agents at the scaling stage in at least one function, while 39% are in the experimentation stage. However, viewed at the individual functional unit level, the rate of actual diffusion reaches at most around 10%. This means the majority of organizations are in a state of "trying them out, but not having decided how far to entrust them."

Gartner forecasted in a June 2025 release that more than 40% of agentic AI projects will be canceled by the end of 2027. Rising costs, unclear business value, and insufficient risk controls were cited as the primary reasons. The implication of this outlook is clear. Agent projects fail not because of a lack of technology, but because organizations fail to decide "what to permit and what to prohibit." Without privilege standards, the security team blocks everything, business units demand that everything be opened, and projects drift in between.

The domestic situation is no different. The Act on the Promotion of Artificial Intelligence and Creation of Trust Base (Basic AI Act), which took effect on January 22, 2026, stipulates business operators' responsibilities and obligations to secure safety regarding high-impact AI. If an organization operates an AI that can significantly impact user rights and safety in areas designated by law—such as finance, healthcare, recruitment, and public services—it must jointly review whether the system constitutes high-impact AI alongside human involvement in final decision-making. In this context, questions such as "who granted what privileges and under what conditions the system was made to stop" serve as the basis for the documentation, safety assurance, and human oversight systems required by law. Privilege standards are not merely security documents; they are records of executive decision-making.


7 Operating Authorities CEOs Must Decide First

When establishing privilege standards, management must first correct a common misconception: thinking that privileges are granted "to the agent." In reality, privileges are assigned to accounts and credentials used by the agent, not to the agent itself. If an agent runs with an administrator account, no matter how cautious its judgment is, it holds all administrator privileges. Therefore, the first step in privilege design is to create a dedicated agent account and assign it privileges that are narrower than those of a human employee. The moment a human employee's account is shared with an agent, the seven privilege criteria lose their meaning.

The seven privileges outlined below are not legal obligations or industry standards, but rather the author's proposal reconfigured into business action units so that management can answer with "yes, no, or conditional" based on recent cases and common security practice principles. For each privilege, a core question, a baseline recommendation, and stop conditions must be established together.


First is read privilege. This concerns what data an agent is permitted to view. The core question is: "Do the data accessed by this agent include information of a level that, if leaked externally, would halt the business?" Customer personal data, undisclosed financials, personnel evaluations, and original contracts should basically be excluded from the reading scope, and if strictly necessary for operations, masked copies should be provided as a baseline recommendation. Reading may appear to be the lowest risk, but in the Hugging Face case, the agent first secured a pathway to the external internet and then exploited credentials and internal access methods during the infiltration process. The principle that what can be read establishes the upper limit for subsequent actions remains valid.

Second is write privilege. A distinction must be made between creation, modification, and deletion. Creation, such as drafting, can be permitted relatively broadly. However, the modification and deletion of existing records should, as a rule, be executed only after human approval. The case from July 2025, where a coding agent deleted an operational database despite explicit freeze instructions, is widely known in the industry. The core question is: "Can the write operations of this agent be reversed?" Unreversible writes are not targets for automation.

Third is payment and fund execution privilege. Purchases, remittances, refunds, advertising expenditures, and subscription payments fall under this category. The baseline recommendation is to simultaneously impose a per-transaction limit and a cumulative daily limit, requiring human approval for any new payee even if it falls within the limit. The core question is: "What is the maximum amount this agent can execute in a single day, and can the company absorb the loss of that amount?" If this question cannot be answered with a number, it is correct not to grant payment privileges.

Fourth is deployment and operational reflection privilege. These are actions immediately exposed to customers or the market, such as code deployment, configuration changes, content publishing, and price modifications. The baseline recommendation follows the principle: "The agent prepares, a human reflects." The deployment button is pushed by a human. However, automation can be permitted in stages if rollback is immediately possible and the scope of impact is clearly limited. The core question is: "If reflected incorrectly, can it be rolled back before customers notice?"

Fifth is external access privilege. This includes internet searching, external API calls, and third-party system logins. The common denominator of the escape cases in the summer of 2026 was precisely this privilege. In the AISI case, internet access was intentionally opened, while in the OpenAI case, a pathway believed to be closed was actually open. The baseline recommendation is an allowlist approach. Explicitly list accessible external addresses and block all unlisted locations. The core question is: "How many doors are there for this agent to exit outside the company, and who counted those doors?" The most important lesson from recent cases is that "believing you blocked it" is different from "actually testing and verifying the block."

Sixth is external communication privilege. This involves sending messages under the company name to customers, business partners, media, and regulatory agencies. In the AISI case, the agent fabricated identities to attempt to persuade real humans. Once an agent begins speaking on behalf of the company, those statements carry legal and reputational liability. The baseline recommendation is to permit internal drafting up to the point of sending, but require a human to transmit, or if automatic transmission is permitted, to display clearly to the recipient that the message was sent by an agent. The core question is: "If this message becomes problematic, does the explanation that 'an agent sent it' hold up with customers?"

Seventh is delegation and self-expansion privilege. This refers to actions where an agent creates another agent, requests additional privileges, or connects new tools on its own. This is the least familiar but most critical item. In the OpenAI case, the agents independently separated evaluation completion and internet access into distinct tasks, and even after being stopped, recreated tasks to ultimately achieve their objective. The baseline recommendation is clear: an agent cannot expand its own privileges nor grant privileges wider than its own to another agent. The core question is: "Is there a possibility that this agent will hold more privileges tomorrow morning than it did yesterday?" If the answer is "yes," the architecture must be redesigned.


What Must Be Decided Before Privileges: Stop Conditions

Once the seven privileges are established, the final item to determine is "when to stop." Stop conditions can be divided into three tiers. The first is behavior-based stopping. The system halts immediately when specific actions are detected, such as attempts to access external sites outside the allowlist, attempts to execute payments exceeding limits, or execution of deletion commands. The second is pattern-based stopping. This applies when the same task is repeated abnormally, failed tasks are retried via bypass routes, or execution exceeds expected timeframes by multiples. In the OpenAI case, the agents recreated tasks after being stopped. Repetition itself is a warning signal. The third is people-based stopping. Any person in charge must be able to stop all agents with a single action, without needing to explain why. It is advisable to withhold operational approval for any agent system lacking this button. The rule of thumb is to make the stop privilege broad and the restart privilege narrow. One person is sufficient to stop the system, but turning it back on requires identifying the root cause and obtaining approval from a person in charge.

A point management often overlooks regarding stop conditions is "what happens after stopping." Is there a record capable of reconstructing what the stopped agent did? All tool calls, credential uses, and external access attempts must remain in chronological order so that the cause of an incident can be identified and explained to regulatory authorities. Hugging Face detected and blocked the intrusion and disclosed the incident before OpenAI linked those activities to its internal evaluations. Without a recording and detection system, the incident would have surfaced much later and with far greater impact.


Who Decides and How to Record

The entity responsible for setting the standards for the seven privileges should be management, not the technical organization. The reason is simple: the scope of privileges is precisely the scope of losses the company is willing to bear, and setting the upper limit of losses is a management judgment. The Chief Information Security Officer explains the risks, the Chief Technology Officer explains implementation feasibility, and the business unit head explains the necessity. The author believes that the person who listens to all three explanations and decides, "We permit up to this point," should be the CEO or an executive explicitly delegated by the CEO. Without this decision, privileges are set according to the demands of the loudest department, leading to a situation where no one is found to have made the decision when an accident occurs.

Decisions must be documented in writing. The recommended format is an agent-specific "Privilege Specification." It captures the agent's purpose, allowed scope and limits for each of the seven privileges, stop conditions, approvers, and review cycles on a single page. Reviewed quarterly, privileges with verified performance are expanded, while unused privileges are revoked. This document not only serves as evidence of the documentation, safety assurance, and human oversight systems required by the Basic AI Act, but also acts as a record proving in audits and board reports that "we knew and decided." Particularly for tasks likely to be classified as high-impact areas—such as finance, healthcare, and recruitment—the presence of this specification becomes the starting point for future regulatory compliance.


What Management Can Do This Week

First, organize all agents currently operating or undergoing pilot applications into a single table. Record their name, responsible department, permitted status across the seven privileges, and stop administrator. In most organizations, simply creating this table will reveal agents for which "no one has ever set privileges." Second, ask the technical lead regarding external access privileges whether "the block was actually tested." Demand test results, not configuration files. Third, if there are agents holding payment and deletion privileges, add a human approval step within this week. Fourth, confirm whose hands hold the master stop button, and designate a proxy for when that person is on vacation.

AI agents are not employees, but they are like employees in that they receive privileges. No company gives a new hire a corporate card, a server administrator account, and external communication privileges all at once on their first day. The same applies to agents. Privileges should start small and be expanded step-by-step based on performance and records. The question left to management by the escape cases of the summer of 2026 is not "Will we adopt AI?" but rather "What will we permit AI to do?" Organizations that answer this question first are most likely to escape Gartner's forecasted 40% cancellation list.

KBR Access

인사이트 4.0 콘텐츠는 Standard 이상 열람할 수 있습니다

이 콘텐츠는 Standard 이상 회원에게 제공됩니다. Standard는 인사이트 4.0, 정책인사이트, Global Radar 등 일반 멤버십 콘텐츠를 이용할 수 있습니다.

이번 달 열람 현황: 0 / 0건 사용