News analysis · 15 September 2026

South Korea's AI Agent Security Guide: Govern Capabilities, Not Labels

By the ELYMENT AI editorial team · Free to read

South Korea's Korea Internet & Security Agency (KISA) said on 15 September 2026 that it is developing an updated AI Security Guide focused on agentic AI services, with a checklist and possible common controls for physical AI. The guide is not yet final and is not a binding rule. Its direction is still useful for every operator: classify AI by what it can do, then increase identity, permission, approval, monitoring and stopping controls as its ability to affect systems and the physical world grows.

Six luminous security gates rise from a digital assistant toward industrial machinery beneath the headline KISA Moves AI Security to the Action Layer.
Original ELYMENT.AI editorial illustration.

What KISA has announced

Reuters reported that KISA, an agency under South Korea's Ministry of Science and ICT, is revising an AI Security Guide first published in 2025. The new version is expected to address risks arising as companies deploy agentic AI and to include a security checklist. It may also set out common control measures for physical AI that interacts with devices or machinery.

This is development work, not a completed standard. Reuters said the guide is not specifically aimed at high-performance frontier models, and KISA has not yet published the final checklist. Businesses should therefore treat the announcement as a signal about security architecture, not as evidence of compliance or a new legal obligation.

KISA's broader direction is already visible. On 7 July 2026 it published an AI Security Threat Response Manual covering AI-specific threat classification and diagnosis, industry threat scenarios and responses. OWASP's Top 10 for Agentic Applications 2026 likewise focuses on systems that plan, act and make decisions across workflows. The shared message is that agent security extends beyond model output quality.

Agent risk changes with capability

The word 'agent' is too broad for approval. One system may only answer questions from an approved knowledge base. Another may read customer records, draft an email, alter a database, make a payment or control machinery. They should not inherit the same risk rating because they share a label or model.

Risk rises with authority, reach and reversibility. A weak answer from a read-only assistant can mislead a person. The same failure in a write-enabled agent can corrupt records; in an execution agent it can trigger an external commitment; in physical AI it can affect equipment and safety. Security reviews should therefore bind controls to capabilities and consequences.

Use a six-level capability matrix

Classify each deployed workflow at its highest enabled level:

  • Chat: generates an answer but has no tools. Control grounding, disclosure, data handling and output evaluation.
  • Read: retrieves from bounded systems without changing them. Add least-privilege identity, source allowlists, query limits and access logging.
  • Draft: prepares an action for a person to release. Make the approval object, evidence and intended recipient visible before submission.
  • Write: changes data in a limited, reversible scope. Enforce field and record boundaries, rate limits, validation and tested rollback.
  • Execute: creates external effects such as publication, purchasing or access changes. Add spend and recipient limits, dual approval for high-impact actions, idempotency and reconciliation.
  • Physical: influences devices or machinery. Require independent interlocks, local stopping controls, safe-state behaviour and testing outside the model's own decision loop.

Attach controls to the highest consequence

Record the level in the service inventory, alongside the model version, connected tools, data classes, credential owner and accountable human. Reassess it whenever a connector, permission or automation step changes.

For each level, test the failure that matters most. Can untrusted content redirect the agent? Can it cross tenant or data boundaries? Can it select the wrong recipient, repeat an irreversible action or claim success when the external system failed? Can an authorised person stop it without relying on the model to cooperate?

Evidence should include denied-action tests as well as successful paths. Keep durable records of the instruction, retrieved context, tool call, approval, external response and final state. Separate emergency stopping and safety interlocks from the agent itself.

What business leaders should do next

Ask every AI owner to replace the single 'agent' category with the six-level capability profile. Freeze deployments whose actual authority is unclear. Set a minimum control set for each level, then require a new approval when the system moves upward or gains a higher-consequence tool.

KISA's final guide may provide a useful national checklist, but businesses do not need to wait to adopt the underlying principle. ELYMENT AI's earlier analysis of frontier AI control assessments, human approval workflows and physical AI standards offers deeper frameworks for these layers. ELYMENT AI can help turn a mixed portfolio of copilots, agents and physical systems into a capability inventory with evidence-based release gates.

Sources

Continue learning

Frequently asked questions

Has South Korea issued final AI agent security rules?

No. KISA said it is developing an updated guide and checklist. The final document had not been published when Reuters reported the work on 15 September 2026.

Why classify agents by capability?

Because systems described as agents can range from read-only assistants to software that changes records, creates external commitments or controls machinery. Their permissions and consequences require different safeguards.

What should trigger a new security review?

A change in model, tool, credential, data source, permitted action, autonomy, physical interface or failure consequence should trigger reassessment and relevant testing.

Explore ELYMENT AI