Everyone's AI, From Civil Petitions to Banking? What Worries Me Most Is Hacking

The features promised by the government's "Everyone's AI" initiative are genuinely appealing. Beyond a chatbot that answers questions, the idea is for AI to handle civil petition filings, bookings of all kinds, and administrative work on people's behalf.

What if it could even support banking tasks? You would simply describe what you want, and the AI would find the needed information, fill out applications, make reservations, and process tasks according to set procedures.

If such a service were properly implemented, it could greatly reduce citizens' time and effort. Especially if it specializes in Korea's laws, administrative procedures, and each agency's systems, it could build a territory that foreign general-purpose AI cannot easily follow.

But one issue worries me more than how flashy the features are.

If an AI that handles citizens' administrative and financial affairs on their behalf gets attacked, how far could the damage spread?

The Project Naver Was Dropped From Is Not This Project

Let me start with the facts.

In January 2026, in the government's "sovereign AI foundation model" program, Naver Cloud was excluded from the first-round evaluation on the grounds that its use of the encoder and weights from China's Alibaba Qwen model did not meet the originality criteria. To say it was dropped simply for fine-tuning a Chinese model would not be accurate.

That program and "Everyone's AI" are separate programs. Naver was not dropped from the Everyone's AI program; it chose not to participate.

My question lies elsewhere. Securing sovereign AI technology matters, but building a service that handles citizens' real work requires solving many problems beyond model performance.

An AI that speaks well and an AI that safely executes administrative work are two entirely different things.

One IP Address Is Not a Hack. The Real Danger Is the Connected Permissions

What concerns me most is server security.

A server connected to the internet has an address reachable from outside. The mere fact that a server's IP address is known does not make hacking possible. With firewalls, access control, authentication, and security patches properly in place, an IP address alone cannot be used to break in.

The problem is what that server is connected to.

When an ordinary website is attacked, the damage can mean defaced posts, leaked personal data, or service outages. Serious enough on its own, of course.

But if an AI agent is connected to petition systems or financial services, and holds identity-verification data or task-processing authority along the way, the story changes.

If attackers take over the AI service's server or steal its credentials and abuse the authority that server holds, the damage could spread beyond a simple website breach into other systems.

Suppose, for example, the AI holds the authority to submit a civil petition on a user's behalf. If attackers steal that authority or exploit the AI's execution flow, applications or changes the user never intended could occur.

With financial tasks, the harm could be more direct. Account-inquiry permission and money-transfer permission carry different levels of danger, and the permission to read information must be strictly separated from the permission to execute real transactions.

Of course, for such harm to actually occur, there must be a concrete vulnerability or a path for abusing permissions. A national administrative network does not automatically fall open just because an AI server is connected to the internet.

What worries me is exactly this connection structure.

If It Connects to Administrative Networks Nationwide, the Risk Bar Must Change First

The "administrative network" here does not mean one giant network. Each agency's systems and security boundaries differ, and not every system is directly connected to every other.

Still, if many agencies' petition systems are made usable through a single AI service, those connection points become critical security boundaries.

Which systems can the AI directly access? What credentials does it store? Is an incident at one agency contained so it cannot spread to another?

The answers to these questions must be clear.

Especially for a service handling citizens' personal data and administrative records, far stricter security standards than an ordinary commercial chatbot are required. Deceiving the AI into misbehaving, exploiting stolen accounts or credentials, and abusing external systems' authority must all be considered together.

A wrong answer from an AI and a wrongly executed administrative procedure differ in the nature of their harm.

So How Should We Block It?

Just because an AI service performs administrative work, it must not be built with direct access to every system.

First, there must be a clear security boundary between the AI service and the core systems of government agencies. Even if the AI server is breached, network and permissions must be separated so that authority alone cannot reach other systems.

Second, the AI must be given only the minimum permissions it needs. The fact that it can look up petition information is no reason to also grant it the power to alter or submit petitions at will. Inquiry, drafting, submission, cancellation, and financial-transaction permissions must be separated.

Third, significant actions must go through the user's explicit confirmation. Drafting an application and actually submitting it must be separate steps, and tasks that can cause monetary loss, like transfers, need separate authentication and approval procedures.

Fourth, every execution must be logged. It must be traceable who requested what, which information the AI used, and which tasks it ran. There must also be a system to immediately revoke permissions and investigate damage when anomalies are found.

Fifth, security validation under real-attack assumptions is needed before launch. Not just the model's own safety, but the entire structure connected to external systems must undergo penetration testing, permission-misuse testing, and failure-recovery testing.

These measures will not make the risk disappear entirely. But they are essential to limiting the AI's authority and the blast radius when an attack succeeds.

Is Big Tech Simply Unable to Do It?

Global big tech companies are developing agent technology too. Techniques for browsing the web and performing multi-step tasks have already appeared.

That does not mean every company allows unlimited handling of government petitions or bank transactions on users' behalf.

There is a gap between what is technically possible and what can be safely offered at scale. Risks like personal data leaks, mistaken transactions, stolen permissions, and legal liability only grow more important as a service grows.

So the reason big tech does not fully offer such features cannot be explained by lack of technical skill alone. Safety and liability, business strategy, and regulation may all play a role.

The same goes for domestic services. Building an AI specialized in Korea's administrative procedures is meaningful enough, but securing a specialized model does not automatically resolve security and liability questions.

I Want to See the Security Design Before the Features

If "Everyone's AI" takes root as a service every citizen can conveniently use, that would be welcome. Reducing complex administrative procedures, finding support programs people need, and handling repetitive work on their behalf clearly has value.

But as the service moves beyond petition filing into bookings, personal data lookup, and financial transactions, it needs a correspondingly high level of verification.

In particular, there are four things I want confirmed.

• Is it designed so that a breach of the AI cannot spread damage into other administrative systems?
• Where are personal and credential data stored, and who can access them?
• When the AI executes something other than what the user intended, how is it stopped and rolled back?
• When a wrongful application or financial transaction occurs, who takes responsibility and remedies the harm?

Before concrete answers to these questions are available, flashy feature introductions alone cannot establish a service's safety.

I am not trying to reject the "Everyone's AI" vision itself. Rather, I believe an AI that acts on citizens' real affairs must meet far higher standards than an ordinary chatbot.

The more the AI acts on behalf of citizens, the more strictly its authority must be limited.

Convenience is visible, but the risk of security incidents is usually invisible. And once an incident happens, it may already be too late.

For Everyone's AI to truly become a service for the people, it must state clearly not only what it can handle, but which systems it must never touch no matter what.