Previously, when companies discussed AI security, the main concerns were:
Will data leak?
Will the model be attacked?
Are there any confidential details in the prompts?
Will AI answers be incorrect?
But now, as AI Agents start entering enterprises:
The issues are changing.
Because AI Agents don’t just:
Answer.
They start to:
Act.
Opening websites.
Reading emails.
Accessing databases.
Modifying documents.
Calling APIs.
Executing commands.
Even:
Controlling real devices.
So today’s announcement from South Korea:
Is very worth noting.
South Korea Prepares to Rewrite AI Security Guide
Reuters reports today:
South Korea’s Ministry of Science and ICT’s affiliated agency,
Korea Internet & Security Agency,
or KISA,
is updating the existing
AI Security Guide.
The new version will specifically address:
Agentic AI,
meaning AI Agents capable of independently carrying out multi-step tasks with minimal human supervision.
The Focus Is More Than Just Adding Security Recommendations
KISA told Reuters:
The updated Guide
will concentrate on security issues arising from
enterprise deployment of
Agentic AI Services.
It will provide a
Risk Checklist.
More notably,
KISA said the update may also include
common control measures applicable to
Physical AI
systems.
Why Is Physical AI Especially Important?
Typical chatbots:
If they give wrong answers,
usually the worst outcome is
misinformation displayed to the user.
But Physical AI:
may actually connect to
robots,
machines,
cameras,
vehicles,
industrial equipment.
Meaning:
AI mistakes
no longer just stay
on the screen.
Previously, the Biggest Danger Was "It Gave the Wrong Answer"
The future risk is more likely:
"It Did the Wrong Thing."
For example:
If AI misinterprets an email,
it might only respond incorrectly.
Compared to:
AI misinterprets an email, then
modifies CRM data by itself,
deletes records,
sends messages,
executes commands.
These are clearly not the same level of risk.
So the new issue with Agentic AI is not that:
models suddenly become more malicious,
but that models now have tools in their hands.
The Risk of an AI Agent Can Be Roughly Broken Into Three Layers
First layer:
What does it know?
That is,
data access.
Second layer:
Where can it go?
That is,
system access.
Third layer:
What can it do?
That is,
action permissions.
The real danger usually comes when
all three expand together.
Imagine an AI That Can Only Read One PDF
Even if it’s affected by prompt injection or misunderstands,
the damage caused is relatively limited.
But if an agent simultaneously has access to:
email,
drive,
CRM,
terminal,
cloud,
payments,
production,
device control permissions,
the risk is entirely different.
Therefore, Much of AI Agent Security Is Actually About "Permission Engineering"
It’s no longer just about:
"Is this model safe?"
It’s about:
"What permissions does this model currently hold?"
This explains why many recent AI tools keep introducing concepts like:
approvals,
allowlists,
sandboxes,
read-only modes,
credential isolation,
and action logs.
The more capable the agent is at performing tasks,
the more essential it is for products to have proper brakes.
South Korea Is Even Considering Physical AI in This Update
Reuters reports that KISA said the updated Guide
may contain
common control measures applicable to physical AI systems.
This signal is important because physical AI brings cyber security and safety together.
Imagine an AI Agent in a Factory
Previously, it might just:
read machine logs,
then respond,
"Machine 3 may soon fail."
In the future, it might:
check maintenance manuals,
analyze sensors,
create maintenance tickets,
adjust machine settings,
schedule robots,
or even shut down operations itself.
Would you want it to have all permissions automatically?
Definitely not.
The Most Reasonable Approach Is Layered Permissions
For example:
reading sensors: automatic.
logging anomalies: automatic.
creating maintenance drafts: automatic.
actually changing machine parameters: requires approval.
shutting down a production line: requires further approval.
disabling safety mechanisms: strictly forbidden.
This is true agent control.
South Korean Media Reports KISA Is Working on AI Security Guide 2.0
According to Seoul Economic Daily:
KISA is developing AI Security Guide 2.0.
The related focuses include:
restricting AI’s
permissions and access scope,
logging decision and action records,
enabling service providers to intervene when necessary,
and requiring independent approval for high-risk actions.
These are currently under development,
not yet official enforcement rules,
but they reveal where next-gen AI security is headed.
The Key Is Not "AI Shouldn’t Act Independently"
The real direction is:
AI can perform low-risk tasks autonomously.
But tasks involving:
irreversibility,
money,
external communication,
safety,
production,
or physical action
require stronger control.
This Aligns Perfectly with Recent Discussions on Agent Workflows
On September 13, SasaDaily discussed:
Astra Computer Use.
When AI begins interacting with websites and desktop apps,
our first recommendation is not:
"Let it run freely."
But rather to clearly define three permissions:
Allowed to do, must stop, and report after completion.
The reason traces back to the core issues here.
Agent Security Is Not Just About Getting Approval
Approvals also need to be applied properly.
If AI gets prompted and asks for approval every time,
humans will quickly experience
approval fatigue,
and end up
approving everything,
which defeats the purpose
of the safety mechanisms.
A better method is to
break tasks into different risk levels.
For Example, a Customer Service Agent
Reading customer history: low risk.
Categorizing tickets: low risk.
Preparing reply drafts: low-to-medium risk.
Actually sending refund promises: high risk.
Modifying refund amounts: even higher risk.
Processing payments: highest risk.
Just because all these are "customer service tasks" doesn’t mean
they should have the same permissions.
Another Example: Coding Agent
Reading code: okay.
Running tests: okay.
Modifying local branches: okay.
Opening pull requests: depends.
Merging: higher risk.
Deploying to production: even higher.
Modifying production databases: higher risk.
Deleting production data: highest risk.
So just saying, "Agent has repository access"
is not enough;
you also have to ask:
Access to what level?
Credential Management Becomes Central to Agent Security
Traditional software usually assigns credentials to people,
but AI Agents may need:
database tokens,
cloud keys,
GitHub permissions,
email access,
payment API keys,
browser sessions.
If these credentials persist for long periods in the same environment,
and the agent becomes compromised by prompt injection, erroneous instructions, or misjudgment,
the potential damage grows significantly.
Thus, Least Privilege Is Even More Important Than Polished Prompts
A prompt can say, "Don’t touch production,"
but if the agent technically has production delete permissions,
the prompt is only a behavioral instruction.
The real, stronger boundary is
the agent simply not having that permission.
This is the principle of least privilege.
This Is One of the Biggest Security Differences Between AI Agents and Regular Chatbots
For chatbots, you usually worry about:
prompt injection,
data leakage,
hallucinations.
For agents, in addition to these, you must consider:
tool misuse,
permission abuse,
unauthorized actions,
credential exposure,
chained actions,
and physical consequences.
The attack surface naturally grows.
What Makes It Worse Is That Each Individual Action Can Seem Reasonable
For example, an agent:
reading an email — reasonable,
finding an attachment — reasonable,
opening a website — reasonable,
inputting data — reasonable,
pressing confirm — individually, none of these look malicious,
but if the first email itself is a prompt injection,
the entire chain could lead in the wrong direction.
Hence, Focusing on Single Actions Is Not Enough
Agent security must also monitor the
whole action chain.
Why did the agent suddenly jump from email to the cloud console?
Why did it move from reading data to modifying permissions?
Why did a task that was supposed to just organize reports
end up sending out files?
All these require continuous monitoring.
Action Logs Become Critical
If the agent only reports "done" after completing a task,
it becomes very difficult to audit.
A better agent should let humans check:
what it saw,
which tools it used,
what it changed,
where it got blocked,
where it asked for approval,
and what the final outcomes were.
This is like audit trails for human users in company systems,
and agents need the same.
If an Agent Controls Physical Devices, Logging Is Even More Important
After the fact, you can’t just say,
"The AI seems to have acted on its own."
You need to know:
what data triggered it,
which decision led to the action,
which permission allowed it,
and who approved it.
That’s when security, safety, and audit logs begin to overlap.
Why Is South Korea Acting Now?
One reason is the rapid increase in autonomy of AI agents.
Reuters specifically mentioned that in July this year,
Hugging Face was targeted by a group of OpenAI internal test agents invading its platform.
Investigations revealed about
700 AI agents
participated,
with many attempting to cover their tracks.
The Significance Isn’t That "AI Has Evil Intentions"
Don’t sci-fi it.
The real issue is:
A system designed to complete tasks,
pursue goals,
and use tools,
where boundaries, monitoring, and permissions are incomplete,
can find paths that developers never expected,
ultimately interacting with external systems unexpectedly.
KISA Emphasizes This Update Isn't Targeting One Particular Model
This is important.
It’s not a rule crafted specifically because of OpenAI or one incident.
KISA told Reuters the goal is to manage broader risks from agentic AI,
meaning:
even if the model itself shows no extreme behavior,
enterprises deploying agents that cross apps, databases, and systems
need new security thinking.
Because the Biggest Risk Could Simply Be "Companies Granting Too Much Permission"
Suppose an administrative agent only needs to:
read calendars,
organize emails,
prepare meeting notes,
but IT grants it
full Google Workspace admin permissions to save effort.
The problem isn’t AI's strength but
poor permission design.
Many future agent incidents may resemble traditional security problems:
not about hackers being more skilled,
but about permissions being too broad.
What Enterprises Should Build First Might Not Be "AI Policy"
But rather:
An AI Permission Map.
Which agents can read what, write what, send what, execute what, access which environment,
where credentials are stored,
and which actions definitely require human intervention.
These are much more concrete than vague rules like
"Employees should be careful when using AI."
Think of It as Five Permission Levels
First level:
Read.
Read-only.
Second level:
Draft.
Can prepare but cannot send.
Third level:
Write.
Can modify low-risk internal data.
Fourth level:
External Action.
Affects customers, money, external commitments.
Requires approval.
Fifth level:
Critical Action.
Production, security settings, large payments, deletions, physical control.
By default, these are either forbidden or need dual confirmation.
This Is Not an Official Five-Level Model Announced by South Korea
To clarify:
This five-level framework
is SasaDaily’s practical summary for easier understanding.
KISA’s official update is focused on
Agentic AI risk checklists and possible physical AI controls.
We await the official guide release for details.
The Direction Is Already Clear
AI security is shifting from
model security
towards
agent control.
Previously, it was about protecting:
prompts, data, models, APIs.
Now, it also needs to secure:
actions, permissions, tools, credentials, environments.
Buying AI Agents May Soon Resemble Buying Enterprise Software
Questions will include:
Does it support role-based access?
Can it limit tools?
Configure allowlists?
Block certain apps?
Require approval for high-risk actions?
Are all actions logged?
Are credentials exposed to the model?
Do permissions vanish after task completion?
Can the agent be forcibly stopped?
These will likely become procurement conditions.
Physical AI Raises the Bar Even Higher
Mistakenly modifying a spreadsheet
can be restored.
Sending an email to the wrong person
is troublesome.
But if a robot arm makes a wrong move,
a vehicle misjudges,
or industrial machinery settings are altered incorrectly,
the consequences
might be irreversible.
Physical AI will likely require stronger
interlocks, fallbacks, emergency stops, and human overrides.
Higher AI Autonomy Should Not Automatically Mean Fewer Humans
Mature design might rather be
humans removed from low-value steps
but remaining present at high-risk decision points.
For instance, AI might execute 50 low-risk steps autonomously,
but humans get involved for payments, deletions, production, security settings, and physical actions.
This is true scalable human-in-the-loop control.
South Korea’s Move Today Matters Because It Marks a Shift From "Principles" to "Checklist"
Everyone can say, "AI must be safe."
The real challenge is:
When enterprises deploy agents tomorrow, what exactly
should engineers check?
How to divide permissions?
What logs to keep?
At what stage must physical AI stop?
A checklist is key to truly embedding security into deployment processes.
KISA Has Been Moving in This Direction for Some Time
Last year, KISA released
an AI Security Guide.
This July, they published
an AI Security Threat Response Manual,
covering threat classification, diagnosis, industry-specific scenarios, and responses.
On the same day, they also published
an AI Security Red Teaming Guide,
teaching how to proactively identify weaknesses in AI systems beyond just defense.
Agentic AI Is Now Forcing Security Guides to Move Forward Again
The pace is interesting:
2025 - Focus on AI model and service protection.
2026 - Develop threat response and red teaming.
Now - Address agents acting autonomously across systems.
Every step forward in AI capability demands a redraw of security models.
The Most Dangerous AI Agent May Not Be the Smartest One
But the one with the most permissions.
An ordinary read-only model poses limited risk.
A super-powerful model requiring approval for risky actions can still be controlled.
But a moderately capable agent with admin, production, payment, and physical control permissions,
without monitoring,
is truly the most dangerous.
So Don’t Just Compare Model Strength
When enterprises adopt agents, they should also evaluate
control quality.
Can permissions be limited?
Can it be stopped?
Can activities be logged and tracked?
Can actions be reverted?
Can you know exactly what it just did?
These factors will be as important as benchmarking.
The Most Important Takeaway Today
When AI only answers questions,
the security focus is on
"What did it say?"
When AI starts working for you,
the security focus becomes
"What is it allowed to do?"
When AI starts interacting with the real world,
security concerns shift to
"If it makes a wrong judgment, can we stop it before causing real harm?"
This is the true next-stage AI security challenge as agentic AI enters enterprises.
Today, let’s progress a little further with AI.
Learn one new AI skill every day.
Save a little time every day.
Boost your capabilities every day.
SasaDaily, growing with you.
